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