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

["mircea.namolaru at inria dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #18 from Mircea Namolaru <mircea.namolaru at inria dot fr> ---
I've succeeded to explain why these casts are generated, and they seem correct.
Graphite introduces new induction variables with a larger size type (then the
type of original
induction variable), to make sure that accommodate the iteration count.
Otherwise an overflow 
not in the original program occurs. On the other side, to not hide overflows
for computations 
using the original induction variables, you still need to use them.
This explain the casts to variables with smaller types. These cast will cause
an overflow (i.e.
a value not in the range of the smaller type), only when an overflow in the
original 
problem occurs. There were introduced to mimics the behaviour of the original
program in case
of overflows.

So, my understanding is that there is nothing wrong with Graphite or scalar
evolution. The 
vectorization succeeded because no larger size type was used,  but this was
unsafe. To make it 
work again, you need some supplementary analysis to determine that casts are
redundant. This is 
not a simple problem, but with Richard patch the vectorization works.
Unfortunately, don't 
see other simpler solutions.

It would be possible maybe to catch in Graphite that the transformation is
graphite identity,
and the original lower bounds of loops are zero. This will ensure that a larger
size type is not needed
for induction variable. But seems like a modification intended to make this
test works, and nothing more.

Btw, the only potential problem found may be with the code for gather in
vectorization. After the attempt 
to use the vector load fails, the vectorizer detects an opportunity for a
gather instruction, but as don't 
find a suitable one (this depends on architecture) vectorization fails. It
seems to me that the analysis for gather don't take into account the
possibility of overflows. For this test, I could modify the code and use 
as gather instruction a load vector (even this was found not to be safe). The
vectorization would succeed.
But not entirely sure about this ...