On Tue, Sep 13, 2016 at 2:36 PM, Wilco Dijkstra <wilco.dijks...@arm.com> wrote: > Richard Biener <richard.guent...@gmail.com> wrote: >> On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra <wilco.dijks...@arm.com> >> wrote: >>> Richard Biener wrote: >>> >>>> Yeah ;) I'm currently bootstrapping/testing the patch that makes it >>>> possible to >>>> write all this in match.pd. >>> >>> So what was the conclusion? Improving match.pd to be able to handle more >>> cases >>> like this seems like a nice thing. >> >> I'm stuck with fallout and making this work requires some serious >> thought. Don't >> hold your breath here :/ >> >> The restricted case of strchr (a, 0) -> strlen () can be made working >> more easily >> but I didn't yet try to implement a restriction only allowing the >> cases that would work. >> >> Meanwhile the strlenopt pass would be an appropriate place to handle >> this transform >> (well, if we now agree on its usefulness). > > I'd like to pick this up again so we can make GCC7 a bit less inefficient for > this case. > (original thread: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00870.html) > > 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. Richard. > Wilco > >
