[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946

--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 3 Jun 2016, shiva0217 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
> 
> --- Comment #14 from Shiva Chen <shiva0217 at gmail dot com> ---
> I'm not sure my understanding was correct.
> 
> To my understanding, TYPE_OVERFLOW_UNDEFINED is true imply that signed overflow
> won't occur.
> 
> E.g. 
> 
> in tree-scalar-evolution.c
> 
> simple_iv (...)
> {
>   ...
>   iv->no_overflow = (!folded_casts && ANY_INTEGRAL_TYPE_P (type)
>                      && TYPE_OVERFLOW_UNDEFINED (type));
> } 
> 
> At the beginning, I thought we could use TYPE_OVERFLOW_UNDEFINED to guard the
> transformation from (short)abs((int)short_var) to abs (short_var).
> 
> The transformation should be safe if overflow won't occur.

But only overflow in type int is guaranteed to not occur.

> From Richard's comment 13
> 
> If we defined a new gimple ABSU_EXPR (x), then undefined behavior gimple IR
> could be avoided and the transformation could always been done.
> 
> ABS_EXPR (x) -> (typeof x) ABSU_EXPR (x)
> 
> ABS_EXPR (INT_MIN) -> (INT) ABSU_EXPR (INT_MIN) -> (INT) (-INT_MIN) -> INT_MIN
> 
> According to the comment from Joseph
> https://gcc.gnu.org/ml/gcc/2013-06/msg00247.html
> RTL abs are modulo.

Everything in RTL is modulo.

> Could we expand the semantic of ABS_EXPR
> which allow ABS_EXPR (INT_MIN) -> INT_MIN directly ?
> 
> Then the semantic of ABS_EXPR could be the same as RTL abs.

We could, but then this would effectively say that for ABS_EXPR
TYPE_OVERFLOW_WRAPS always holds.

> And I saw the comment in fold-const.c
> 
> bool
> tree_unary_nonnegative_warnv_p (enum tree_code code, tree type, tree op0,
>                                 bool *strict_overflow_p)
> {
>   if (TYPE_UNSIGNED (type))
>     return true;
> 
>   switch (code)
>     {
>     case ABS_EXPR:
>       /* We can't return 1 if flag_wrapv is set because
>          ABS_EXPR<INT_MIN> = INT_MIN.  */
>       if (!INTEGRAL_TYPE_P (type))
>         return true;
>       if (TYPE_OVERFLOW_UNDEFINED (type))
>         {
>           *strict_overflow_p = true;
>           return true;
>         }
> 
> Dose it mean ABS_EXPR already support the semantic ABS_EXPR (INT_MIN) ->
> INT_MIN ?

Yes, of course - only if !TYPE_OVERFLOW_UNDEFINED the situation
that ABS_EXPR (x) < 0 can validly occur (for x equal to the minimum 
value of its type).

> Please correct me, if I misunderstanding something.
> 
>