On Thu, Sep 15, 2016 at 09:52:34AM +0200, Richard Biener wrote:
> On Wed, Sep 14, 2016 at 3:45 PM, Jakub Jelinek <ja...@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)).
>
> 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).
Sure.
Jakub
