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

            Bug ID: 90437
           Summary: Overflow detection too late for VRP
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

bool f(unsigned a, unsigned b, unsigned*c){
  if(a>10)__builtin_unreachable();
  if(b>10)__builtin_unreachable();
  *c = a + b;
  return *c < a;
}

In the .optimized dump, we still have

  _9 = .ADD_OVERFLOW (a_2(D), b_3(D));
  _1 = REALPART_EXPR <_9>;
  _8 = IMAGPART_EXPR <_9>;
  *c_5(D) = _1;
  _7 = _8 != 0;
  return _7;

We have code in VRP to simplify IFN_ADD_OVERFLOW when the arguments have
interesting ranges, but this call only appears in the widening_mul pass. In
this particular case, expand optimizes the code properly, but in general _8
would be used in a GIMPLE_COND and we would have a number of further
optimizations to make.

We could either have an earlier pass than widening_mul detect a+b<a and
introduce IFN_ADD_OVERFLOW, or VRP could detect a+b<a and optimize it as if it
was IFN_ADD_OVERFLOW (without introducing it).

Reply via email to