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? Wilco
