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?
> +
> +/* 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.
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?
match.pd isn't my area of speciality, so if Andrew or Richard suggest
something different, their review matters more than mine.
jeff
