On 7/23/2026 6:18 AM, Naveen wrote:
Recognize conditional addition and subtraction patterns equivalent to
Y + abs (X) and Y - abs (X).
For signed integral types, perform the addition or subtraction in the
corresponding unsigned type and convert the result back to the original
type. This avoids introducing signed overflow and preserves wrapping
semantics including when X is TYPE_MIN_VALUE.
Do not perform the transformation when signed overflow traps or is
sanitized.
gcc/ChangeLog:
PR tree-optimization/56223
* match.pd (X >=/> 0 ? Y + X : Y - X): New simplification.
(X <=/< 0 ? Y - X : Y + X): Likewise.
gcc/testsuite/ChangeLog:
PR tree-optimization/56223
* gcc.dg/tree-ssa/pr56223.c: New test.
* gcc.dg/tree-ssa/pr56223-2.c: New test.
* gcc.dg/tree-ssa/pr56223-3.c: New test.
* gcc.dg/tree-ssa/pr56223-4.c: New test.
Signed-off-by: Naveen <[email protected]>
So the new patterns apply to both generic and gimple. In the former
case I believe the argument types are not required to match. Do we have
any concerns about @0 or @1 being a floating point type and potentially
a sNaN here? Similarly since this matches in generic, aren't we
dropping an evaluation of X in which case don't we have to verify X has
no side effects?
I think we can side-step this class of problems by checking if (GIMPLE)
in addition to the type tests your doing. Through gimple's type system
we'll know that @0 must also be an integer type due to the comparison.
With @0 being an integer type, the gimple type system will also ensure
@1 is an integer type.
With the additional check to force these patterns to only fire for
GIMPLE this is OK to push to the trunk after the usual testing.
jeff
