search for: vecreg

Displaying 5 results from an estimated 5 matches for "vecreg".

2011 Jan 29
3
[LLVMdev] Possible CellSPU Bug?
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...
2017 Apr 03
2
Scheduler: modelling long register reservations?
Hello, My out-of-tree target features some high latency instructions (let's call them FXLV). When an FXLV issues, it reserves its destination register and execution continues; if a subsequent instruction attempts to read or write that register, the pipline will stall until the FXLV completes. I have attempted to encode this constraint in the machine scheduler (excerpt at bottom of email).
2017 Apr 24
3
Debugging UNREACHABLE "Couldn't join subrange" in RegisterCoalescer (out-of-tree backend)
...rget-cpu"="generic" "unsafe-fp-math"="false" "use-soft-float"="false" } Here's the tail-end of the log, with debugging turned on: $llc bugpoint.reduced.simplified.bc -debug ... 208B %vreg13:sub_64_1<def> = COPY %vreg34:sub_64_1; VecRegs:%vreg13,%vreg34 Considering merging to VecRegs with %vreg34 in %vreg13 RHS = %vreg34 [160r,240r:0)[240r,384B:1)[400B,480r:1)[480r,496r:2)[496r,672r:3) 0 at 160r 1 at 240r 2 at 480r 3 at 496r L00000020 [240r,384B:1)[400B,672r:1) 0 at x 1 at 240r L00000010 [160r,384B:1)[400...
2011 Jan 31
0
[LLVMdev] Possible CellSPU Bug?
...HWVecInst<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
2011 Jan 31
1
[LLVMdev] Possible CellSPU Bug?
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