[PATCH] Use strlen when searching for a nul char

[Mike Frysinger]

On 19 Apr 2016 17:27, Adhemerval Zanella wrote:
> On 19-04-2016 14:57, 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') ?
> > 
> > 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 ?
> 
> Personally I am not very found on the string2.h header and its intrinsic logic,
> which contains optimization logic that might not be true depending of the
> architecture string optimization.
> 
> Also for the specific optimization does we really need to keep pushing for 
> these specific inline implementations? I would prefer a much simple string2.h
> header than a convoluted one we have today.

i don't have a real opinion on keeping it or just tossing the whole
thing out.  but if we keep it, i think we should be adding the bits
that make sense (like my question above) rather than half-assing it.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160419/10b13a3e/attachment.sig>