[LLVMdev] Possible CellSPU Bug?

[B. Scott Michel]

 On Sat, 29 Jan 2011 17:21:07 -0600, David Greene wrote:
> I'm working on enhancing TableGen's type checking and it triggered 
> with
> a problem in CellSPU's specification:
>
> XSHWv4i32: 	(set VECREG:v8i16:$rDest, (sext:v8i16 
> VECREG:v4i32:$rSrc))
>
> It's complaining that v4i32 is not smaller than v8i16, which is true 
> in
> the sense of vector bit size, and true in the sense of vector element
> size.  To me, a sign extension from i32 to i16 makes no sense.
>
>>From the .td file, it looks as if src and dest types have been 
>> swapped:
>
> class XSHWVecInst<ValueType in_vectype, ValueType out_vectype>:
>     XSHWInst<(outs VECREG:$rDest), (ins VECREG:$rSrc),
>              [(set (out_vectype VECREG:$rDest),
>                    (sext (in_vectype VECREG:$rSrc)))]>;
>
> multiclass ExtendHalfwordWord {
>   def v4i32: XSHWVecInst<v4i32, v8i16>;
>
> The multiclass name leads me to believe this was supposed to sign 
> extend
> from i16 to i32 but the XSHWVecInst class takes the types in SRC -> 
> DST
> order, not DST <- SRC order.
>
> Is this pattern as intended, or did I find a real problem?
>
>                        -Dave

 It's intentional. Everything on Cell is a vector, with the exception of 
 loads and stores. Unless you really want to write code that determines 
 the exact vector element that needs to be changed and do all of the 
 juggling to modify that element. There are no individual registers.

 If it's easier to flip the order of the operands, then do so. That's 
 just style.


 -scooter
-- 
 B. Scott Michel, Ph.D.
 Director, Computer Systems Research Department
 The Aerospace Corporation
 Ofc: (310) 336-5034
 Cell: (310) 426-4993