https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908
--- Comment #5 from Yuri Gribov <tetra2005 at gmail dot com> --- (In reply to Marc Glisse from comment #4) > (In reply to Yuri Gribov from comment #3) > > As noted in comments, this is more about adding new API to Glibc than GCC > > (they have corresponding > > https://sourceware.org/bugzilla/show_bug.cgi?id=19920 about this). So can > > this be closed? > > I don't think so (at least not for that reason). Whatever glibc does, this > is still a missed optimization in gcc. Well, as we all know there are a lot of missing optimizations in GCC :) I think the real question is whether it's ever going to be fixed if there's no standard API for this code pattern which we can recognize as builtin. I believe the answer is "No". ATM GCC does not vectorize even the simplest memcpy equivalent code: // gcc tmp.c -O3 -mtune=native -ftree-vectorize -o- -S void memcpy_(char * __restrict a, char * __restrict b, unsigned n) { unsigned i; for (i = 0; i < n; ++i) a[i] = b[i]; } so I don't think it'll be able to recognize memcchr in reasonable timeframe. Adding a std. function in Glibc and then treating it as std. builtin in GCC would be straightforward and cost-effective solution but the ball is on Glibc side and they didn't sound very positive. Thoughts?
