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
David Greene wrote:> class XSHWVecInst<ValueType in_vectype, ValueType out_vectype>:> def v4i32: XSHWVecInst<v4i32, v8i16>;> Is this pattern as intended, or did I find a real problem?Looks like a bug to me. xshw (extend signed half-word(16bits) to word(32bits)) takes a v8i16 and produces a v4i32. This has likely gone unnoticed as there is only one type of vector register class (i.e. VECREG) that is used for all vectors. Nice catch :) Are there more of these? kalle -- "Modern computing machines are very complex objects" -von Neumann introducing the NORC, 1954
Kalle Raiskila <kalle.raiskila at nokia.com> writes:> Looks like a bug to me. xshw (extend signed half-word(16bits) to > word(32bits)) takes a v8i16 and produces a v4i32. This has likely gone > unnoticed as there is only one type of vector register class (i.e. > VECREG) that is used for all vectors. > > Nice catch :) Are there more of these?I don't know. I stopped implementing the stricter typechecking when I saw this. I wanted to make sure there wasn't some official trickery going on. :) -Dave
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? > > -DaveIt'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