This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use strlen when searching for a nul char



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 ?
> -mike
> 

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]