This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Optimize strchr (s, 0) to strlen
On 15/09/16 14:49, Jakub Jelinek wrote:
> On Thu, Sep 15, 2016 at 01:38:45PM +0000, Wilco Dijkstra wrote:
>> __rawmemchr is not the fastest on any target I tried, including x86, so GLIBC's
>> current default behaviour of always using __rawmemchr is inefficient. GCC doesn't
>> support __rawmemchr at all, so the strlen optimization can't optimize it.
>
> Why? It knows you are targeting glibc, and if it sees rawmemchr (or
> __rawmemchr) in the headers as well, it can emit that.
> As for speed, there is no inherent reason why rawmemchr should be slower
> than strlen, on the contrary. So, if on some target rawmemchr is slower
> than strlen, most likely it has never been implemented there properly, or
> somebody improved strlen without bothering to improve rawmemchr at the same
> time.
>
from libc point of view, rawmemchr is a rarely used
nonstandard function that should be optimized for size.
(glibc does not do this now, but it should in my opinion.)
in case of static linking strlen is most likely linked
into your binary already, but rawmemchr is not, so
emitting calls to it increases code size.
>> strchr is significantly slower than strlen, so generating that is a bad idea too.
>>
>> So the only reasonable optimization is to always emit a + strlen (a).
>
> I disagree. Another, on glibc more reasonable, optimization is to make sure
> rawmemchr is fast enough.
>
libc should not imlpement n variants of similar functions,
it is a maintainance problem and it makes the code bloated.
(glibc even has asm implementations, which history tells
is a bad idea: string functions had bugs, performance
regressions and other problems because the asm is not
future proof and it is hard to guarantee consistent
behaviour across targets e.g. memchr on x86_64 is broken
right now BZ 19387)