On Thu, 7 Jul 2011, Sebastian Pop wrote: > 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?
The idea sounds good to me and the middle-end-like looking pieces look good. I'd appreciate a 2nd look from Tobias. Thanks, Richard.