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