similar to: [LLVMdev] Relocatability of LLVM code

On Thu, Aug 20, 2009 at 6:42 AM, Gary Benson<gbenson at redhat.com> wrote: > Hi all, > > As I understand it, LLVM's JIT memory manager works by allocating a > 16Mb block of memory and generating native code into it.  Once that > block is exhausted no more functions can be JIT compiled.  I'm trying > to figure out ways to work around this limitation. Nope, I

No, I don't. Cheers, Gary Dale Johannesen wrote: > This looks OK to check in, do you have write access? > > On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > > >Dale Johannesen wrote: > >>On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > >>>I'm trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch

Hi Evan, Evan Cheng wrote: > The patch looks great. But I do have one comment: > > +let usesCustomDAGSchedInserter = 1 in { > + let Uses = [CR0] in { > + let Uses = [R0] in > + def ATOMIC_LOAD_ADD_I32 : Pseudo< > > The "let Uses = [R0]" is not needed. The pseudo instruction will be > expanded like this later: > > + BuildMI(BB,

Hi all, I want to implement llvm.memory.barrier on PowerPC. The implementation would be the single instruction "sync", but currently it's defined with: setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand) in lib/Target/PowerPC/PPCISelLowering.cpp, which causes it to be a noop. I replaced the "Expand" with "Legal" in the hope I'd get an error message

Look for createVirtualRegister. These are examples in PPCISelLowering.cpp. Evan On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > Hi Evan, > > Evan Cheng wrote: >> The patch looks great. But I do have one comment: >> >> +let usesCustomDAGSchedInserter = 1 in { >> + let Uses = [CR0] in { >> + let Uses = [R0] in >> + def ATOMIC_LOAD_ADD_I32 :

Dale Johannesen wrote: > On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >

Hi all, When I've been disassembling JIT-compiled functions I've noticed they all have the same three random instructions after them: bns- cr5,0xd04bbfe8 stfs f10,-16404(r3) stfs f10,-16404(r3) Is this meant to be there? Cheers, Gary -- http://gbenson.net/

Hi all, When you genetate code on PowerPC you need to explicitly invalidate the instruction cache to force the processor to reread it. In LLVM there is code to do this for function stubs on Macintosh, but not for other platforms and not for JITted code generally. The attached patch adds support for GNU platforms, but I can't figure out a nice way to call it for all generated code. Can

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

Hi all, I'm getting a weird error if I run llc on the attached module. Did I do something wrong (llc says the module is broken, also attached) or is this a bug? Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.bc Type: application/octet-stream Size: 2060 bytes Desc: not available URL:

Committed. Thanks! Evan On Jul 11, 2008, at 1:07 PM, Gary Benson wrote: > Hi Evan, > > Evan Cheng wrote: >> This does not patch cleanly for me (PPCISelLowering.cpp). Can you >> prepare a updated patch? > > This should work, though I won't have access to my test box now until > next Thursday so no guarantees :) > > Cheers, > Gary > > -- >

Thanks. One thing though, who's Chris? Cheers, Gary Dale Johannesen wrote: > OK, I've checked it in for you, thanks. Please do contact Chris > about write access. > > On Aug 22, 2008, at 12:38 AMPDT, Gary Benson wrote: > > No, I don't. > > > > Cheers, > > Gary > > > > Dale Johannesen wrote: > > > This looks OK to check

Hi, I noticed that if you create a switch with multiple cases going to the same destination, then if that destination contains phis you need to add the incoming value an equivalent number of times. The attached code seems wrong, but it compiles as correct, and removing the duplicated incoming node causes an error. Is this expected? Cheers, Gary -- http://gbenson.net/ -------------- next part

Hi all, I've been working on making a non-architecture specific port of OpenJDK these past few months. It's interpreter-only at present, and very slow, and I'd like to use LLVM to add some kind of JIT to it. So far I'm just trying to figure out how it would all slot in. The existing code in OpenJDK is written to accomodate different JITs, so integrating peripheral stuff like

Hi all, I'm trying to figure out how to add the instructions required for llvm.atomic.cmp.swap.i32 on PowerPC. I figured out LWARX (patch attached) but the other two (CMP_UNRESw and STWCX) require multiple instructions: let Defs = [CR0] in { def STWCX : Pseudo<(outs), (ins GPRC:$rS, memrr:$dst, i32imm:$label), "stwcx. $rS, $dst\n\tbne-

Hi all, I'm trying to use LLVM on a 64-bit PowerPC Linux box. This platform has a weird way of dealing with function pointers which I don't think LLVM has support for. Can anyone point me in the right direction so I can start implementing it? The problem is this. On most platforms, a function pointer in C is the address of the entry point of the function. This is the case for 32-bit

Hi all, I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled my patch (attached) on the implementation in X86, but when I try and compile my test file (also attached) with llc I get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably means my "membarrier"

OK, I've checked it in for you, thanks. Please do contact Chris about write access. On Aug 22, 2008, at 12:38 AMPDT, Gary Benson wrote: > No, I don't. > > Cheers, > Gary > > Dale Johannesen wrote: >> This looks OK to check in, do you have write access? >> >> On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: >> >>> Dale Johannesen

It could be stubs, data in text sections. Jump tables, constant pools, etc.? Are they ever executed? Evan On Jul 3, 2008, at 2:15 AM, Gary Benson wrote: > Hi all, > > When I've been disassembling JIT-compiled functions I've noticed they > all have the same three random instructions after them: > > bns- cr5,0xd04bbfe8 > stfs f10,-16404(r3) > stfs

Duncan Sands wrote: > Can you please attach IR which can be compiled > to an executable (and shows the problem). I've been generating functions using a builder and then compiling them with ExecutionEngine::getPointerToFunction(). Is there some way I can get compilable IR from that? Cheers, Gary -- http://gbenson.net/