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.

> 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
>

Reply via email to