This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use strlen when searching for a nul char
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Tue, 19 Apr 2016 18:01:39 -0300
- Subject: Re: [PATCH] Use strlen when searching for a nul char
- Authentication-results: sourceware.org; auth=none
- References: <DB3PR08MB008978DA72CE0E1B93BB477483A60 at DB3PR08MB0089 dot eurprd08 dot prod dot outlook dot com> <20160419175706 dot GI5369 at vapier dot lan> <571694A4 dot 4020603 at linaro dot org> <20160419205116 dot GO5369 at vapier dot lan>
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.
> -mike
>
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.