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

Wilco Dijkstra Wilco.Dijkstra@arm.com
Thu Sep 15 13:51:00 GMT 2016


Richard Biener wrote:
> On Wed, Sep 14, 2016 at 3:45 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Wed, Sep 14, 2016 at 03:41:33PM +0200, Richard Biener wrote:
> >> > We've seen several different proposals for where/how to do this simplification, why did you
> >> > say strlenopt is best? It would be an unconditional strchr (a, 0) -> a + strlen (a) rewrite,
> >> > ie. completely unrelated to what strlenopt does. We do all the other simplifications based
> >> > on constant arguments in builtins.c and gimple-fold.c, why is strchr (s, 0) different?
>>>
> >> I was thinking about the case where strlen opt already knows strlen
> >> (a).  But sure, gimple-fold.c
> >> works as well.
> >
> > I think for the middle-end, using strchr (a, 0) as canonical instead of a + strlen (a)
> > is better, and at expansion time we can decide what to use (a + strlen (a)
> > if you'd expand strlen inline, rather than as a function call, or
> > __rawmemchr (which if libc is sane should be fastest), or strchr, or a + strlen (a)).

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

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

> OTOH that then argues for doing it in strlenopt because that knows
> whether we maybe
> already computed strlen (a) (which might have other uses than adding to a).

strlenopt can already change strchr (a, 0) into strlen (a) + a when strlen has been
called before it, so that part is already done. However it doesn't optimize a strlen after 
a strchr, so if the expansion is done late you'd end up with a redundant strlen.

That means the expansion would need to happen either before or very early in strlenopt
(likely an extra pass at init time to avoid upsetting the strlen optimization - we want to
treat any strchr as a real strlen).

Wilco



More information about the Gcc-patches mailing list