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