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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

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.