[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, graphite generates expressions like MIN_EXPR <(long)n, (long)mid> < 0
that fold does not simplify.  Adding a match.pd pattern to shorten min/max
expressions we end up with

  <bb 4>:
  _28 = MIN_EXPR <n_5(D), mid_6(D)>;
  _29 = _28 > 0;
  if (_29 != 0)
    goto <bb 5>;
  else
    goto <bb 8>;

  <bb 5>:
  _30 = MIN_EXPR <n_5(D), mid_6(D)>;
  _31 = (signed long) _30;
  _32 = _31 + -1;

but still niter analysis isn't able to constrain the max iterations to
sth that SCEV could later use to prove that (int) graphite_IV doesn't wrap.

Analyzing # of iterations of loop 2
  exit condition [0, + , 1](no_overflow) < (signed long) _30 + -1
  bounds on difference of bases: -9223372036854775808 ... 9223372036854775806
  result:
    zero if _30 <= 0
    # of iterations (unsigned long) ((signed long) _30 + -1), bounded by
9223372036854775806
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17:
note: Symbolic number of iterations is (unsigned long) MAX_EXPR <_30, 1>

so niter analysis can be improved here as _30 is of type int and even if
_30 were INT_MIN the upper bound would be 2147483647.

We can improve that by stripping sign-/zero-extensions from vars in
bound_difference.

With those two improvements we can vectorize the first loop.