Hi Andrew, Jeff, Thank you both for the detailed review !
I am sorry, I completely misunderstood the note about splitting the testcases out in v2. I will squash the testcases and the match.pd changes back into a single, unified patch and submit it shortly as v3. Thanks, Souradipto On Mon, 8 Jun, 2026, 12:42 am Andrew Pinski, <[email protected]> wrote: > On Sun, Jun 7, 2026 at 11:57 AM Jeffrey Law > <[email protected]> wrote: > > > > > > > > On 6/3/2026 2:51 AM, Souradipto Das wrote: > > > This patch introduces a simplification rule in match.pd to reduce > bitwise > > > expressions against zero. Specifically, it simplifies patterns where a > > > variable checked against zero is combined via bitwise AND/OR with a > compounded > > > bitwise OR check against zero. > > > > > > PR tree-optimization/125442 > > > > > > gcc/ChangeLog: > > > > > > * match.pd: Add simplification rules for > > > (a == 0) | ((a | b) == 0) -> (a == 0) and > > > (a != 0) & ((a | b) != 0) -> (a != 0). > > > --- > > > gcc/match.pd | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/gcc/match.pd b/gcc/match.pd > > > index 8a2de136e..4a2f9a784 100644 > > > --- a/gcc/match.pd > > > +++ b/gcc/match.pd > > > @@ -6660,6 +6660,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > > (simplify > > > (bitop (neeql @0 @1) (neeqr (bit_ior @0 @1) integer_zerop)) > > > { constant_boolean_node (bitop == BIT_IOR_EXPR, type); })) > > > + > > > +/* (a == 0) | ((a | b) == 0) -> (a == 0) -- PR125442 > > > + (a != 0) & ((a | b) != 0) -> (a != 0) -- PR125442 */ > > > + > > > +(for bitop (bit_and bit_ior) > > > + neeq (ne eq) > > > +(simplify > > > + (bitop:c (neeq@2 @0 integer_zerop) (neeq (bit_ior:c @0 @1) > integer_zerop)) > > > + @2)) > > > #endif > > This may have been asked and answered already, but is simplifying to @2 > > or (eq/ne @2 integer_zero) better? > > It is simplifying to @2 here. That is the `(a == 0)`/`(a != 0)` expression. > > > > > Do we need to be careful with types? I'm not 100% sure that @2's type > > is going to match the ultimate type for the pattern. Do we need to do > > any conversion on the output? > > No because @2 is the type of the neeq expression so it should be fine. > > > > > We're dropping references to @1, if this applies before gimple (say in > > generic) do we run the risk of dropping an embedded side effect? > > There is code in genmatch that handles the case of dropping the reference. > That is genmatch.cc (dt_simplify::gen_1): > ``` > /* Search for captures not used in the result expression and > dependent > on TREE_SIDE_EFFECTS emit omit_one_operand. */ > ``` > The time a match pattern needs to deal with generic in a special way > is when we are making something that was conditional to unconditional > and vice versa. There is expr_no_side_effects_p for that. > > > > > Overall I think it's going in the right direction, we just need to make > > sure the details are correct for the various corner cases. > > > > Andrea, you have any thoughts on these issues? You know this framework > > far better than I. > > I think the only thing is the testcases as part of one full patch. I > think Souradipto misunderstood my first review where I said to split > the new testcases out. I meant to create a new testcase file rather > than splitting the patch into two. > > Thanks, > Andrea > > > > > Jeff >
