Re: [PATCH v2] tree-optimization: Recognize add/sub absolute-value idiom [PR56223]

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