https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that as far as vectorization is concerned the issue is that the IV used to
perform the memory accesses is not affine:
<bb 6>:
# graphite_IV.4_34 = PHI <0(5), graphite_IV.4_35(7)>
_37 = (int) graphite_IV.4_34;
_36 = a[_37];
_38 = b[_37];
_39 = _36 + _38;
_45 = (int) graphite_IV.4_34;
a[_45] = _39;
graphite_IV.4_35 = graphite_IV.4_34 + 1;
if (graphite_IV.4_34 < _33)
goto <bb 7>;
else
goto <bb 8>;
<bb 7>:
goto <bb 6>;
the IV _37 is (int) { 0, +, 1 } with graphite_IV being signed long. Thus
_37 may wrap if graphite_IV becomes larger than INT_MAX. I don't see how
this is related to the MIN/MAX_EXPRs. Thus it would be nice if ISL could
compute bounds for the IVs (and if we can input bounds on the original IVs,
of course).
VRP may be able to see that _33 is computed as
if (n_5(D) > 0)
goto <bb 4>;
...
<bb 4>:
_28 = (signed long) n_5(D);
_29 = (signed long) mid_6(D);
_30 = MIN_EXPR <_28, _29>;
_31 = _30 > 0;
if (_31 != 0)
goto <bb 5>;
...
<bb 5>:
_32 = MIN_EXPR <_28, _29>;
_33 = _32 + -1;
and thus _33 is [0, INT_MAX - 1] but it isn't able to do that (and VRP
runs too late anyway). VRP misses that for _30 > 0 it can infer
that mid_6 > 0, but that's probably a too difficult thing to asses
with it working as SSA propagator and ASSERT_EXPR insertion happening
before actual propagation (it needs to know n_5 > 0 to be able to do
that insertion). A DOM style propagation would have less issues with
deriving proper value-ranges here.
