[PR tree-optimization/64946] Push integer type conversion to ABS_EXPR argument when possible.

[Joseph Myers]

On Fri, 8 Jan 2016, Matthew Wahab wrote:

> Hello,
> 
> The C/C++ front-ends apply type conversions to expressions using ABS
> with integral arguments of type smaller than int. This means that, for
> short x, ABS(x) becomes something like (short)ABS((int)x)). When the
> argument is the result of memory access, this restricts the vectorizer
> apparently because the alignment of the operation doesn't match the
> alignment of the memory access. This causes two failures in
> gcc.target/aarch64/vec-abs-compile.c where the expected abs instructions
> aren't generated.
> 
> This patch adds a case to convert_to_integer_1 to push the integer type
> conversions applied to an ABS expression into the argument, when it is
> safe to do so. This fixes the failing test cases.

Note that, for example, (int) labs (INT_MIN) is well-defined if long is 
wider than int (in GNU C, where conversion of out-of-range values to 
signed types is well-defined).  But abs (INT_MIN) is undefined.  That is, 
such transformations can never be safe unless the minimum value of the 
type of the ABS_EXPR argument is not a possible value of the contained 
expression.

What's your definition of safe?  I'd expect a patch like this to contain 
lots of testcases verifying that the transformation occurs in cases where 
it's OK, but that (int) labs (int_var) does not end up with an ABS_EXPR on 
type int (for example) (in the absence of a guarantee that said ABS_EXPR 
will return INT_MIN for an argument of INT_MIN - which might be the case 
for -fwrapv, but can't be otherwise because *_nonnegative*_p assume 
ABS_EXPR always produces a nonnegative result).

-- 
Joseph S. Myers
joseph@codesourcery.com