On Tue, 2016-09-13 at 12:36 +0000, Wilco Dijkstra wrote: > Richard Biener <richard.guent...@gmail.com> wrote: > > > > On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra <Wilco.Dijkstra@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? >
BTW, there are two PRs for this: 61056 and 32650. Please take them into account when committing something for this issue. Cheers, Oleg
