[PATCH] Use strlen when searching for a nul char

[Mike Frysinger]

On 19 Apr 2016 18:01, Adhemerval Zanella wrote:
> On 19-04-2016 17:51, Mike Frysinger wrote:
> > 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.
> 
> My idea is to cleanup the header bit a bit until we could just removei
> it. That's why I would prefer to not add any more optimization bits
> on it.

if everyone agrees on that direction, then slowly culling it WFM
-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/a9334a33/attachment.sig>