> From: Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> > Date: Thu, 18 Feb 2021 11:12:26 +0100
> On Thu, Feb 18, 2021 at 12:35 AM Hans-Peter Nilsson via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > If we're not going to eliminate the clz, it's better for the > > comparison to use that result than its input, so we don't > > extend the lifetime of the input. Also, an additional use > > of the result is more likely cheaper than a compare of the > > input, in particular considering that the clz may have made > > available a non-zero condition matching the original use. > > Of course the non-zero compare can execute concurrently > with the clz if we use the input which can result in faster > operation. It's one of the many cases where local folding > doesn't tell us enough. One of the usual issues with > single_use checks is that the IL is not fully DCEd while > we fold it and thus dead uses can make sth !single_use > even though it really is single_use. > > Also if there's a use of the input live at the point of the > compare we want to replace it's likely better to do the > transform. Yeah, all depending on the code context. I guess these simple match.pd transformations will grow some conditions. > > The "s" modifier doesn't stop this situation, as the > > transformation wouldn't result in "an expression with more > > than one operator"; a gating single_use condition on the > > result is necessary. > > Note that :s was done this way for the use in VN where > we can this way CSE c != 0 with an earlier a >= 0. > > It might be an interesting idea to allow match.pd consumers > to "switch" behavior of :s according to their needs. Like, as a heuristic for a non-ooo-target, to mean single_use? Yes, good idea! > > Regtested cris-elf and x86_64-linux. > > Ok to commit? > > OK. Done as a2ef38b1f94d, thanks for the review. > gcc/testsuite: > PR tree-optimization/99142 > * testsuite/gcc.dg/tree-ssa/pr99142.c: New test. JFTR; oops: ^ Spurious "testsuite/" removed. brgds, H-P
