[LLVMdev] Possible CellSPU Bug?

[David Greene]

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