similar to: [LLVMdev] llvm JIT to another target code?

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:

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

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 Aug 13, 2007, at 9:11 PM, Chris Lattner wrote: > Nope, passes work within a module, they can't create/delete them. So there is no possibility to write a pass to arrange functions and globals in a different than the given way? No way to partition the structure new? I would really like to know how code is generated for heterogeneous architectures like Cell? I thought they use a

Hi, I'm yet working on the LLVM ExecutionEngine portability (2.6 release version) and I get two different problems depending on the platform. The first problem concerns compilation on MacOs X (10.5.5) with an X86 processor, when trying to compile my own project containing the ExecutionEngine class and the linker class. I get links problem with "_ffi_type_sint16",

Hi Is there any Altivec optimized libVorbis implementation source code out there ? The only thing I'v found is that message: http://lists.xiph.org/pipermail/vorbis-dev/2003-October/007835.html but the link is dead, so the source code is lost (forever ?). I need to decode from 10 to 30 ogg files on my PS3 on the fly (files are already in memory, so I'm not I/O bound) and do something

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

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.

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

I compiled the following code with llvm-gcc (4.2.1) and llc (2.3svn) for spu of Cell broadband engine processor. > cat add.c float add (float a, float b) { return a + b; } > llvm-gcc add.c --emit-llvm -c -o add.bc > llc -march=cellspu add.bc Cannot yet select: 0x867c700: v4f32 = SPUISD::INSERT_MASK 0x8670800 Abort (core dumped) But llc returned the above error. If I

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

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

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 :)

/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

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 that CellSPU >> loads and stores on 16-byte boundaries. Consequently,

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.

Chen, see http://llvm.org/docs/GettingStarted.html#pf_12 ...Takumi ps. Excuse me, PE+ (aka pep) means "Executable file format for WIndows x64". 2011/5/16 陈晓宇 <xychen0921 at gmail.com>: > The stack trace: > > Starting program: > C:\MinGW\msys\1.0\home\xchen\llvm-obj\lib\Target\CellSPU/../.. > /../Debug/bin/tblgen.exe -I

This is a scheduler assertion. It means a value (virtual register) use is somehow scheduled before its definition. Please 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