Hi,
First there are two cleanup patches independent of the fix:
Start counting nesting level from 0.
Do not compute twice type, lb, and ub.
Then the patch that fixes PR47654:
Fix PR47654: Compute LB and UB of a CLAST expression.
One of the reasons we cannot determine the IV type only from the
polyhedral representation is that as in the testcase of PR47654, we
are asked to generate an induction variable going from 0 to 127. That
could be represented with a "char". However the upper bound
expression of the loop generated by CLOOG is min (127, 51*scat_1 + 50)
and that would overflow if we use a "char" type. To evaluate a type
in which the expression 51*scat_1 + 50 does not overflow, we have to
compute an upper and lower bound for the expression.
To fix the problem exposed by Tobias:
> for (i = 0 ; i < 2; i++)
> for (j = i ; j < i + 1; j++)
> for (k = j ; k < j + 1; k++)
> for (m = k ; m < k + 1; m++)
> for (n = m ; n < m + 1; n++)
> A[0] += A[n];
>
> I am a little bit afraid that we will increase the type size by an
> order of magnitude (or at least one bit) for each nesting level.
instead of computing the lb and ub of scat_1 in "51*scat_1 + 50" based
on the type of scat_1 (that we already code generated when building
the outer loop), we use the polyhedral representation to get an
accurate lb and ub for scat_1.
When translating the substitutions of a user statement using this
precise method, like for example S5 in vect-pr43423.c:
for (scat_1=0;scat_1<=min(T_3-1,T_4-1);scat_1++) {
S5(scat_1);
we get a type that is too precise: based on the interval [0,99] we get
the type "unsigned char" when the type of scat_1 is "int", misleading
the vectorizer due to the insertion of spurious casts:
# Access function 0: (int) {(<unnamed-unsigned:8>) graphite_IV.7_56, +, 1}_3;
#)
affine dependence test not usable: access function not affine or constant.
So we have to keep around the previous code gcc_type_for_clast_* that
computes the type of an expression as the max precision of the
components of that expression, and use that when computing the types
of substitution expressions.
The patches passed together a full bootstrap and test on amd64-linux.
Ok for trunk?
Thanks,
Sebastian
