On Mon, Jul 25, 2011 at 12:52 PM, Ira Rosen <ira.ro...@linaro.org> wrote: > On 25 July 2011 12:39, Richard Guenther <richard.guent...@gmail.com> wrote: >> On Mon, Jul 25, 2011 at 11:10 AM, Ulrich Weigand <uweig...@de.ibm.com> wrote: >>> Richard Guenther wrote: >>>> On Sun, Jul 24, 2011 at 2:02 PM, Ira Rosen <ira.ro...@linaro.org> wrote: >>>> > On 21 July 2011 15:19, Ira Rosen <ira.ro...@linaro.org> wrote: >>>> >> I reproduced the failure. It occurs without Richard's >>>> >> (http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01022.html) and this >>>> >> patches too. Obviously the vectorized loop is executed, but at the >>>> >> moment I don't understand why. I'll have a better look on Sunday. >>>> > >>>> > Actually it doesn't choose the vectorized code. But the scalar version >>>> > gets optimized in a harmful way for SPU, AFAIU. >>>> > Here is the scalar loop after vrp2 >>>> > >>>> > <bb 8>: >>>> > # ivtmp.42_50 = PHI <ivtmp.42_59(3), ivtmp.42_45(10)> >>>> > D.4593_42 = (void *) ivtmp.53_32; >>>> > D.4520_33 = MEM[base: D.4593_42, offset: 0B]; >>>> > D.4521_34 = D.4520_33 + 1; >>>> > MEM[symbol: a, index: ivtmp.42_50, offset: 0B] = D.4521_34; >>>> > ivtmp.42_45 = ivtmp.42_50 + 4; >>>> > if (ivtmp.42_45 != 16) >>>> > goto <bb 10>; >>>> > else >>>> > goto <bb 5>; >>>> > >>>> > and the load is changed by dom2 to: >>>> > >>>> > <bb 4>: >>>> > ... >>>> > D.4520_33 = MEM[base: vect_pa.9_19, offset: 0B]; >>>> > ... >>>> > >>>> > where vector(4) int * vect_pa.9; >>>> > >>>> > And the scalar loop has no rotate for that load: >>>> >>>> Hum. This smells like we are hiding sth from the tree optimizers? >>> >>> Well, the back-end assumes a pointer to vector type is always >>> naturally aligned, and therefore the data it points to can be >>> accessed via a simple load, with no extra rotate needed. >> >> I can't see any use of VECTOR_TYPE in config/spu/, and assuming >> anything about alignment just because of the kind of the pointer >> is bogus - the scalar code does a scalar read using that pointer. >> So the backend better should look at the memory operation, not >> at the pointer type. That said, I can't find any code that looks >> suspicious in the spu backend. >> >>> It seems what happened here is that somehow, a pointer to int >>> gets replaced by a pointer to vector, even though their alignment >>> properties are different. >> >> No, they are not. They get replaced if they are value-equivalent >> in which case they are also alignment-equivalent. But well, the >> dump snippet wasn't complete and I don't feel like building a >> SPU cross to verify myself. > > I am attaching the complete file.
The issue seems to be that the IV in question, vect_pa.9_19, is defined as vect_pa.9_19 = (vector(4) int *) ivtmp.53_32; but ivtmp.53_32 does not have a definition at all. Richard. > > Thanks, > Ira > > > >> >>> This vector pointer must originate somehow in the vectorizer, >>> however, since the original C source does not contain any >>> vector types at all ... >> >> That's for sure true, it must be the initial pointer we then increment >> in the vectorized loop. >> >> Richard. >> >>> Bye, >>> Ulrich >>> >>> -- >>> Dr. Ulrich Weigand >>> GNU Toolchain for Linux on System z and Cell BE >>> ulrich.weig...@de.ibm.com >>> >> >
