Re: rs6000.md/altivec.md problem in setting of vector registers

[Dale Johannesen <dalej at apple dot com>]

On Mar 3, 2004, at 8:56 AM, Dorit Naishlos wrote:

> Hi,
>
> I think there is a problem in the way we model the setting of subregs 
> (insn
> "insvsi") in rs6000, or rather - a problem in the way reload phase 
> handles
> these patterns when they are generated to express an initialization of 
> a
> vector register. Consider the following example:
>
> typedef int __attribute__((mode(V8HI))) v8hi;
> #define N 1024
> void foo5 (short n){
>     short a[N];
>     v8hi *pa = (v8hi *)a;
> > >  v8hi va = {n,n,n,n,n,n,n,n};
>     int i;
>
>     for (i=0; i<N/8; i++){
>       pa[i] = va;
>     }
>     bar1 (pa[2]);
> }

Those loads and stores in the loop are happening because RA
chose to assign int registers to the va pseudo.  This is obviously
not a good idea and suggests some problem in computing the register 
costs.

 Register 120 costs: BASE_REGS:20000 GENERAL_REGS:20000 
ALTIVEC_REGS:560000
SPEC_OR_GEN_REGS:2048 NON_FLOAT_REGS:20448 MEM:4896

That (from the .lreg dump) doesn't look right, I suggest investigating 
why the
Altivec number is so high.  Comparison with x86 may be helpful.

A couple of observations that won't help with your main problem:
>     short a[N];
>     v8hi *pa = (v8hi *)a;
This sort of thing generally violates strict aliasing rules, and has a 
tendency
not to work as expected when scheduled.   Vectors are outside the 
standard,
but I don't think there's any special handling for aliasing them, is 
there Aldy?
I don't see why pa will necessarily by 16-byte aligned, either, 
although it always
was when I tried.

The shift-i-and-add inside the loop isn't strength reduced, and should 
be.
It is if you change pretty much anything, though, so it's hitting some 
edge case.