similar to: [LLVMdev] Does spu backend works with scalar variable?

On Mar 29, 2010, at 6:50 AM, Kalle Raiskila wrote: > attached is a second try for the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions: > -in vararg handling, registers are marked to be live, to not confuse the register scavenger Looks good. You can try running with -verify-machineinstrs to detect

Chris Lattner skrev: > On Feb 22, 2010, at 6:08 AM, Kalle.Raiskila at nokia.com wrote: >> currently the SPU backend does not handle big stack frames (>16*511 >> bytes) nicely. llc asserts on malformed machine instructions. >> (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first >> operand is not immediate") > > Sounds fine

On Feb 22, 2010, at 6:08 AM, Kalle.Raiskila at nokia.com wrote: > Hello all, > > currently the SPU backend does not handle big stack frames (>16*511 > bytes) nicely. llc asserts on malformed machine instructions. > (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first > operand is not immediate") Sounds fine to me in general. Please write a

/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 included from

Hi, On SPU, variables in the .bss section that are allocated with the .lcomm directive are not aligned on 16 byte boundaries. This causes misaligned loads, as the generated assembly assumes this "default" alignment. A patch to disable .lcomm in favour of '.local .comm' is attached. kalle P.s. As an example, the following function returns '3', when '5' is

As Andy Pinski pointed out, there were some really good reasons why Cell SPU support never made it into gcc 4.2. I've attached the patches from the 4.1.1 compiler, and I've applied+compiled them in my local tree. I suggested creating a branch, but since they appear to be relatively disjoint, the need for a branch doesn't seem necessary. Sorry for the large patch file -- I didn't

Hello, I noticed that the SPU assembly printer prints just ".bss", when gas requires ".section .bss". Now the gas prints out: Assembler messages: Error: expected symbol name Attached is a test case and a patch to fix this. (This time 'make check' passes also ;) kalle -------------- next part -------------- A non-text attachment was scrubbed... Name: spu_bss.patch

hi, either function call in this code makes llc (targeting SPU) assert: declare i8 @return_i8() declare i16 @return_i16() define void @testfunc() { %rv1 = call i8 @return_i8() %rv2 = call i16 @return_i16() ret void } Attached is a patch to fix it, and remove some related redundant code. Does this rather trivial fix warrant a test case? kalle -------------- next part -------------- A

The example code: ; ModuleID = 'struct_2.bc' target datalayout = "E-p:32:32:128-f64:64:128-f32:32:128-i64:32:128-i32:32:128-i16:16:128-i8:8:128-i1:8:128-a0:0:128-v128:128:128-s0:128:128" target triple = "spu" @boolvar = internal global i1 false define void @set_boolvar() nounwind { entry: store i1 true, i1* @boolvar, align 16 ret void } This gets

Hi, attached is a second try for the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions: -in vararg handling, registers are marked to be live, to not confuse the register scavenger -function prologue and epilogue are not emitted, if the stack size is 16. 16 means it is empty - there is only the

Hello all, currently the SPU backend does not handle big stack frames (>16*511 bytes) nicely. llc asserts on malformed machine instructions. (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first operand is not immediate") E.g. the function: define i32 @foo() nounwind { entry: %retval = alloca i32 %big_data = alloca [1000 x i32] store i32 3840, i32*

Thank very much for this answer, so my last question will be: is it possible to use the LLVM JIT on a PS3 with Yellow Dog 6.2 distribution, instead of the LLVM interpreter, by using the PPE as it seems to be similar to 64-bit PowerPC processors? 2009/12/18 Scott Michel <scooter.phd at gmail.com> > Jerome: > > No, there are no plans to JIT to SPU. That's considerably more

Jerome: No, there are no plans to JIT to SPU. That's considerably more complicated -- you'd have to figure out when to JIT to the SPU and live with all of the constraints that the SPU imposes (data reformatting, r/w DMA, ensure your code lives in 256K unless you can manage to interface with the virtual I-cache work.) Basically, it's not trivial and it doesn't quite fit into the

Hi, I'm doing some preliminary work to get Clang to compile for PS3 targets. As an intermediate step in that direction, could someone do me the favor of reviewing and submitting the enclosed patch, or giving me feedback on it? Basically, I need to be able to differentiate the triple for a PS3 target. These are the triples currently used in the gcc-based compiler from the PS3 devkit:

On Jun 4, 2010, at 1:57 AM, <Kalle.Raiskila at nokia.com> <Kalle.Raiskila at nokia.com> wrote: > On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: >> If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. >> > Tried it, and it seems to break quite a big chunk of our tests on SPU :)

Hi, I am using llvm on cell, there are two different cores on cell, one is PPU and the other is SPU. but the JIT'ed code is always for PPU. I am trying to emit code for SPU through JIT. but I face the following questions: 1. I've trace the JIT code, but I still cant find exactly where JIT allocate PPU as it's target. is it done at make time? 2. I am trying to add an option that

Hello > Is there additionnals information to provide to the linker when > compiling llvm on mac os x? Do you have libffi installed somehere? > > > The second question concerns Yellow Dog Distribution(6.2) on CellSPU > processor. Does lli support JIT compilation on CELL? No. As far as I can see, there is no JIT for SPU. -- With best regards, Anton Korobeynikov. Faculty of

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

On Aug 28, 2007, at 6:15 PM, Scott Michel wrote: > On Aug 28, 2007, at 7:02 AM, Dan 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

Hi Micah, On Tue, Jun 19, 2012 at 6:29 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > If the patterns only include SDNodes, then pattern fragments will work. > > I might be wrong, but I've yet to find a way to do it with machine instructions, which is what you seem to have here. I found in the Cell SPU port: lib/Target/CellSPU/SPUMathInstr.td some examples using code