This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Merge to trunk from Graphite branch
Hi,
On Tue, 16 Mar 2010, Sebastian Pop wrote:
> > In Toon's testcase from
> > http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00515.html vectorization fails
> > because scev analysis failure: "evolution of offset is not affine." It
> > probably gets confused by
> >
> > Â# graphite_IV.22_66 = PHI <0(4), graphite_IV.22_67(6)>
> > Âvar.23_77 = (character(kind=4)) graphite_IV.22_66;
> > ÂD.1214_68 = (integer(kind=4)) var.23_77;
> > Âi_69 = D.1214_68 + 1;
> > ÂD.1192_70 = (integer(kind=8)) i_69;
> > ÂD.1193_71 = D.1192_70 + -1;
> > ÂD.1194_72 = (*a_39(D))[D.1193_71];
> >
> > Âinstead (without Graphite)
> >
> > Â# i_1 = PHI <1(3), i_48(5)>
> > ÂD.1192_37 = (integer(kind=8)) i_1;
> > ÂD.1193_38 = D.1192_37 + -1;
> > ÂD.1194_40 = (*a_39(D))[D.1193_38];
> >
>
> Looks like the scev analysis fails because of too many casts
> on the way, otherwise I see no particular difficulty in the code
> generated by Graphite.
Both sequences aren't equivalent, so my guess would be that the
transformation done by graphite actually is buggy or at least suboptimal.
The difference lies in the overflow behaviour. Without graphite, i_1 has
undefined overflow, as D.1192_37 too, hence we can look through the
conversion. With graphite var.23_77 (of unsigned type) has defined
overflow semantics, hence we can't look through that conversion.
Ciao,
Michael.