search for: cellspu

/Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp: In function 'bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, short int&)': /Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp:141: warning: dereferencing type-punned pointer will break strict-aliasing rules In file include...

...ARM running Ubuntu Natty gunzip llvm-2.9rc1.src.tar.gz tar zxvf llvm-2.9rc1.src.tar cd llvm-2.9-build ../llvm-2.9rc1/configure --enable-shared time make clean ;time make CXXFLAGS=-marm CFLAGS=-marm xranby at panda:/media/dh0/llvm-2.9-build$ time make check Failing Tests (64): LLVM :: CodeGen/CellSPU/2009-01-01-BrCond.ll LLVM :: CodeGen/CellSPU/call_indirect.ll LLVM :: CodeGen/CellSPU/extract_elt.ll LLVM :: CodeGen/CellSPU/fcmp64.ll LLVM :: CodeGen/CellSPU/fneg-fabs.ll LLVM :: CodeGen/CellSPU/i64ops.ll LLVM :: CodeGen/CellSPU/immed64.ll LLVM :: CodeGen/CellSPU/privat...

There are LLVM 2.9 RC1 pre-release tarballs source available. You can find them here: http://llvm.org/pre-releases/2.9/ Please download them, build them, and compile things to your heart's content. And most importantly file a bunch of bug reports. :-) Share and enjoy! -bw

I just ran across something interesting: DAGCombine inserts a 64-bit constant as the result of converting a (bitconvert (fabs val)) to a (and (bitconvert val), i64const). The problem: i64 constants have to be legalized for the CellSPU platform. DAGCombine is doing the right thing but it's not doing the right thing for CellSPU and it's damed difficult to work around this "feature". Moreover, the way all of SelectionDAGLegalize and DAGCombne's code is written, it's particularly difficult to "...

...ger operand: 0xe00722c: ch = store 0xcc056f0, 0xe00700c, 0xe007094, 0xe0071a4 <0xcc02bbc:0> alignment=16 [--Crash occurs here--] The crash occurs because the second operand to store is still an i1; it doesn't appear to have been updated to the i8 that was previously legalized. Stores for CellSPU are custom lowered. Is it my responsibility to promote the second operand or should I expect that the store's operands be updated after they have been type-legalized? -scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/l...

llvm[3]: Compiling SPUISelDAGToDAG.cpp for Debug build In file included from /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp:334: /Volumes/mrs5/net/llvm/llvm-build/lib/Target/CellSPU/ SPUGenDAGISel.inc: In member function ‘llvm::SDNode* SPUDAGToDAGISel::Emit_5(const llvm::SDOperand&, unsigned int, unsigned int, llvm::MVT::ValueType, llvm::MVT::ValueType)’: /Volumes/mrs5/net/llvm/llvm-build/...

They looked real enough to me: /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: In function ‘bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, short int&)’: /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: 148: warning: dereferencing type-punned pointer will break strict- aliasing rules /Volumes/mrs5/net/llvm/llv...

...an Gohman wrote: > On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >> It looks like I need to be able to intercept GEP lowering (in >> SelectionDAGLowering::visitGetElementPtr) and insert something else >> other than the shifts and adds. The basic problem is that CellSPU >> loads and stores on 16-byte boundaries. Consequently, the SPU backend >> has to do the load or store differently than most normal >> architectures that have byte-addressable operations. > > In TOT, load and store instructions have an alignment attribute > which is &g...

Chris: I did float this by the dev list first a couple of weeks ago, didn't receive any comments. It's not entirely gratuitous; the rationale for adding a new node class is threefold: a) Convenience for the backends. Since it benefits multiple backends (PPC and CellSPU), it's a logical addition. I reckon the GPU efforts would also benefit. b) Where else would one encapsulate a constant splat predicate? SelectionDAG and SDNode are not good classes for constant splat detection, since it's functionality specific to building vectors. c) Future work. At some p...

Yup, I've got one remaining bug that holding up the CellSPU release. It still has a bunch of warts, but so long as I can get it into shape such that llvm-gcc-4.2 compiles all the way through, then we collectively have something with which to work. I'm getting the following error from llc, the attachments have llc's debug and the .ll files,...

...ease run llc in gdb. Call dumpSchedule() to print out the schedule. Also please let me know which node it is processing at the time of the assertion. Evan On Oct 15, 2007, at 11:48 PM, Scott Michel <scottm at aero.org> wrote: > Yup, I've got one remaining bug that holding up the CellSPU release. > It still has a bunch of warts, but so long as I can get it into > shape such that llvm-gcc-4.2 compiles all the way through, then we > collectively have something with which to work. > > I'm getting the following error from llc, the attachments have llc's &...

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 sen...

...ple of weeks ago, didn't > receive any comments. Ok, I didn't see it, sorry about that. > It's not entirely gratuitous; the rationale for adding a new node > class is threefold: > > a) Convenience for the backends. Since it benefits multiple backends > (PPC and CellSPU), it's a logical addition. I reckon the GPU efforts > would also benefit. I don't see this. Adding some helper methods would have the same functionality. > b) Where else would one encapsulate a constant splat predicate? > SelectionDAG and SDNode are not good classes for co...

...; Also please let me know which node it is processing at the time of >> the >> assertion. >> >> Evan >> >> On Oct 15, 2007, at 11:48 PM, Scott Michel <scottm at aero.org> wrote: >> >>> Yup, I've got one remaining bug that holding up the CellSPU release. >>> It still has a bunch of warts, but so long as I can get it into >>> shape such that llvm-gcc-4.2 compiles all the way through, then we >>> collectively have something with which to work. >>> >>> I'm getting the following error from llc,...

...is: >> >> I did float this by the dev list first a couple of weeks ago, didn't >> receive any comments. >> > > Ok, I didn't see it, sorry about that. It happens. :-) > a) Convenience for the backends. Since it benefits multiple backends (PPC >> and CellSPU), it's a logical addition. I reckon the GPU efforts would also >> benefit. >> > > It's not entirely gratuitous; the rationale for adding a new node class is > threefold: > > I don't see this. Adding some helper methods would have the same > functionality....

...hedule() to print out the schedule. > Also please let me know which node it is processing at the time of the > assertion. > > Evan > > On Oct 15, 2007, at 11:48 PM, Scott Michel <scottm at aero.org> wrote: > >> Yup, I've got one remaining bug that holding up the CellSPU release. >> It still has a bunch of warts, but so long as I can get it into >> shape such that llvm-gcc-4.2 compiles all the way through, then we >> collectively have something with which to work. >> >> I'm getting the following error from llc, the attachments have...

It looks like I need to be able to intercept GEP lowering (in SelectionDAGLowering::visitGetElementPtr) and insert something else other than the shifts and adds. The basic problem is that CellSPU loads and stores on 16-byte boundaries. Consequently, the SPU backend has to do the load or store differently than most normal architectures that have byte-addressable operations. Unfortunately, detecting whether an add is really an add or whether it was generated by a GEP lowering is ambi...

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

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

Kalle: Your patch is similar to what I'd coded (and am testing, which means a couple of hours before I consider committing). Other than cosmetic changes and changing 'NULL' to '0' (it's an integer list, after all). This patch now causes new problems in the CellSPU backend (more stqd's and lqd's), so I have to investigate those before committing the patch. 'make test' is our friend. 'make test' is our friend. 'make test' is our friend. :-) -scooter On Thu, Feb 25, 2010 at 11:25 PM, <Kalle.Raiskila at nokia.com> wrote:...