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?
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?
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?
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.
Jeff
