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.
