On Fri, May 29, 2026 at 10:36 AM Jeffrey Law <[email protected]> wrote: > > > > > On 5/29/2026 10:13 AM, Shivam Gupta wrote: > > Recognize XOR patterns involving zero_one_valued operands compared > > against zero and simplify them to direct equality or inequality tests. > > > > Specifically: > > > > (a == 0) ^ (b != 0) -> a == b > > (a != 0) ^ (b == 0) -> a == b > > (a == 0) ^ (b == 0) -> a != b > > (a != 0) ^ (b != 0) -> a != b > > > > Also handle a specific case: > > (a == 0) ^ b -> b != (a ^ 1) > > > > Regression tested on aarch64-linux-gnu. > > > > gcc/ChangeLog: > > * match.pd: Add simplifications for XORs of zero_one_valued > > comparisons against zero. > > > > gcc/testsuite/ChangeLog: > > * gcc.dg/tree-ssa/bool-eq-bitxor.c: Update expected number > > of optimized XOR forms. > > * gcc.dg/tree-ssa/bool-xor-zero-one-valued.c: New test. > > > > Signed-off-by: Shivam Gupta <[email protected]> > So for the (a == 0) ^ b case, isn't the simplification for that just a > == b rather than b != (a ^ 1)? If both are 0/1 valued, that works, right?
Yes, for 0/1 values, `b != (a^1)` is the same as `a == b` and `a == b` is simpler in gimple so that should be used. > > > > > > + > > +/* For zero_one_valued operands: > > + (a == 0) != (b != 0) -> a == b > > + (a != 0) != (b == 0) -> a == b. */ > > +(for op1 (eq ne) > > + op2 (ne eq) > > + (simplify > > + (ne:c (op1 zero_one_valued_p@0 integer_zerop) > > + (op2 zero_one_valued_p@1 integer_zerop)) > > + (if (types_match (TREE_TYPE (@0), TREE_TYPE (@1))) > > + (eq @0 @1)))) > Do you want to handle an outer EQ here in addition to handling the outer > NE? I think it just inverts the resulting code, right? SImilarly for > the other pattern. Yes I think we should handle an outer ne/eq here too. > > > Do we need conversions on @0 and @1? In particular a conditional > conversion convert? And if we do that, do we need to adjust the > types_match conditional? I did mention that in my review of the other patch where I suggested this one being separate that we should use a convert here. Thanks, Andrea > > match.pd isn't my area of speciality, so if Andrew or Richard suggest > something different, their review matters more than mine. > > jeff
