[PATCH] Optimize strchr (s, 0) to strlen

Jakub Jelinek jakub@redhat.com
Thu Sep 15 14:17:00 GMT 2016


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.

> 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.

	Jakub



More information about the Gcc-patches mailing list