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

[Dale Johannesen]

On Mar 4, 2004, at 4:09 PM, Dorit Naishlos wrote:
>> 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.
>
> Thanks, this indeed looks like the right direction, and it seems to 
> support
> the original suspicion that there is a problem with the "insvsi" 
> pattern of
> the insns that are used to initialize the va pseudo:
>
> (insn:HI 12 11 13 0 (set (zero_extract:SI (subreg:SI (reg/v:V8HI 120 [ 
> va
> ]) 0)
>             (const_int 16 [0x10])
>             (const_int 0 [0x0]))
>         (reg/v:SI 118 [ n ])) 106 {insvsi} (insn_list 11 (insn_list 3
> (nil)))
>     (nil))
>
> When the RA calculates the cost of assigning an ALTIVEC_REG to 
> temporary
> 120 in any of these insns, it checks the related cost using the 
> relevant
> machine mode of the operand in question. The relevant mode should be 
> V8HI.
> However, the "zero_extract" part of the "insvsi" pattern "hides" that, 
> and
> instead, the RA calculates the cost of assigning an ALTIVEC_REG to an
> *SImode* operand. The default for such "impossible" assignments is 
> 10,000.

I don't know if it would be more appropriate to address this in the RA 
code or
the patterns.  Somebody who understands RA better can probably tell you.

There are several cost-computation functions in rs6000.c, especially
rs6000_register_move_cost looks promising.  Doesn't the RA call into
there at some point?  Seems like it should.  That would be the right 
place,
if it does.