On Tue, May 7, 2024 at 10:56 PM Andrew Pinski <pins...@gmail.com> wrote: > > On Tue, May 7, 2024 at 1:45 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > > > > > On 4/30/24 9:21 PM, Andrew Pinski wrote: > > > This adds a few more of what is currently done in phiopt's > > > value_replacement > > > to match. I noticed this when I was hooking up phiopt's value_replacement > > > code to use match and disabling the old code. But this can be done > > > independently from the hooking up phiopt's value_replacement as phiopt > > > is already hooked up for simplified versions already. > > > > > > /* a != 0 ? a / b : 0 -> a / b iff b is nonzero. */ > > > /* a != 0 ? a * b : 0 -> a * b */ > > > /* a != 0 ? a & b : 0 -> a & b */ > > > > > > We prefer the `cond ? a : 0` forms to allow optimization of `a * cond` > > > which > > > uses that form. > > > > > > Bootstrapped and tested on x86_64-linux-gnu with no regressions. > > > > > > PR treee-optimization/114894 > > > > > > gcc/ChangeLog: > > > > > > * match.pd (`a != 0 ? a / b : 0`): New pattern. > > > (`a != 0 ? a * b : 0`): New pattern. > > > (`a != 0 ? a & b : 0`): New pattern. > > > > > > gcc/testsuite/ChangeLog: > > > > > > * gcc.dg/tree-ssa/phi-opt-value-5.c: New test. > > Is there any need to also handle the reversed conditional with the arms > > swapped? If not, this is fine as-is. If yes, then fine with the > > obvious generalization. > > The answer is yes and no. While the PHI-OPT pass will try both cases > but the other (all?) passes does not. This is something I have been > thinking about trying to solve in a generic way instead of adding many > more patterns here. I will start working on that in the middle of > June. > Most of the time cond patterns in match are used is inside phiopt so > having the revered conditional has not been on high on my priority but > with VRP and scev and match (itself) producing more cond_expr, we > should fix this once and for all for GCC 15.
IMO this is a classical case for canonicalization. IIRC in fold we rely on tree_swap_operands_p for the COND_EXPR arms and if we can invert the condition we do so. So there's a conflict of interest with respect to condition canonicalization and true/false canonicalization. We do not canonicalize COND_EXPRs in gimple_resimplify3, but the only natural thing there would be to do it based on the op2/op3 operands, looking at the conditional would dive down one level too deep. Richard. > Thanks, > Andrew Pinski > > > > > jeff > >
