https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Mircea Namolaru from comment #7)
> Graphite generates MAX/MIN expressions.
>
> I've modified Graphite to use the original types of "n" and "mid" in MIN and
> MAX, and to not generate the casts of "n" and "mid" to a longer signed INT
> before MIN/MAX, and the vectorization succeeded.
>
> It seems that it is not a Graphite problem but a scalar evolution one.
> Scalar evolution is not able to handle MIN/MAX expressions in the presence
> of casts. Beside vectorization also further unrolling is prevented.
Can you share a patch with that modification? I'd like to look at the
differences it makes with respect to SCEV / niter analysis. Note that
neither SCEV nor niter analysis handle MIN/MAX_EXPRs explicitely. It might
be that
<bb 2>:
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)
can be simplified to mid_6(D) > 0 by expansion/folding in some way though
if there are no casts in the way. Not sure. I suppose ISL doesn't get to
know that n > 0 if the loop enters (and doesn't exploit that knowledge)?
