On 19 Apr 2016 22:03, Wilco Dijkstra wrote:
>  Mike Frysinger wrote:
> > On 25 Feb 2016 13:04, Wilco Dijkstra wrote:
> >> Remove the strchr (s, '\0') to rawmemchr optimization as using rawmemchr is
> >> a bad idea - I have a patch to add strchr (s, '\0') -> strlen to GCC7.
> >> Like strchr (s, '\0'), rawmemchr (s, '\0') appears a common idiom for finding
> >> the end of a string, however it is not the most efficient way of doing so.
> >> Strlen is a simpler operation which is significantly faster on larger inputs
> >> (eg. on x86 strlen is 50% faster than rawmemchr on strings of 1KB).
> >
> > will there be a change in GCC to also detect rawmemchr(s,'\0') ?
> 
> I wasn't planning to add it - GCC doesn't currently have it as a builtin so support
> would need to be added first. It's unclear how often rawmemchr is used
> elsewhere and what percentage is for finding the end of a string.
> 
> > even then, since this optimization isn't showing up until GCC7, shouldn't
> > we keep some logic here ?  i.e. transform strchr/rawmemchr(s, '\0') into
> > strlen before falling back ?
> 
> If it is common to use an old GCC to build a new GLIBC for a distro then adding
> strchr->strlen with a PREREQ would be useful. But if one typically first builds GCC7
> and then GLIBC with that then it would not matter.

the issue isn't what version of gcc is used to build glibc.  this is an
installed header, and we made guarantees that the installed headers work
with much older versions of gcc at runtime.  those guarantees don't hard
extend to pure-optimizations, but typically we wait much longer for those
versions to cycle out of common use.  dropping code that requires gcc7
(which doesn't even exist yet) doesn't fall into that bucket.
-mike