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

shiva0217 at gmail dot com gcc-bugzilla@gcc.gnu.org
Fri Jun 3 07:08:00 GMT 2016


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.

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.


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.

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 ?

Please correct me, if I misunderstanding something.


More information about the Gcc-bugs mailing list