Reid Kleckner
2011-Apr-01 16:38 UTC
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at apple.com> wrote:>> >> >> Then we would always have the location of the br B instruction in A, as it is pushed onto the stack or saved in link register when A calls B. >> > > Right, unless you wanted to go with direct calls in the JIT. I don't know that inspecting a running program's stack for return values while compiling on a separate thread is sane :) > > That said, the adaptive compilation strategy can always enforce the use of a stub for calls into jitted functions.I think you said what I was going to say, but here's how I see it: getPointerToFunction always returns the address of the stub, so any indirect calls to the function hit the stub. The stub will attempt to backpatch the callsite, and should fail if it is a) outside the JIT or b) an indirect call. Indirect calls will always go through the stub. Direct calls can be backpatched. Alternatively, everything would go through the stub. Finally, you have to be careful about the memory model of the architecture you're dealing with if you care about threads. On x86, if you can align the operand of the call instruction, you can do an atomic update. You will also have to make sure you don't free the old machine code while there are still functions executing in it. An easy (yet inefficient) way to deal with this is to update a refcount on function entry/exit. Reid
Eric Christopher
2011-Apr-01 17:26 UTC
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Apr 1, 2011, at 9:38 AM, Reid Kleckner wrote:> On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at apple.com> wrote: >>> >>> >>> Then we would always have the location of the br B instruction in A, as it is pushed onto the stack or saved in link register when A calls B. >>> >> >> Right, unless you wanted to go with direct calls in the JIT. I don't know that inspecting a running program's stack for return values while compiling on a separate thread is sane :) >> >> That said, the adaptive compilation strategy can always enforce the use of a stub for calls into jitted functions. > > I think you said what I was going to say, but here's how I see it: > > getPointerToFunction always returns the address of the stub, so any > indirect calls to the function hit the stub. The stub will attempt to > backpatch the callsite, and should fail if it is a) outside the JIT or > b) an indirect call. Indirect calls will always go through the stub. > Direct calls can be backpatched. > > Alternatively, everything would go through the stub. > > Finally, you have to be careful about the memory model of the > architecture you're dealing with if you care about threads. On x86, > if you can align the operand of the call instruction, you can do an > atomic update. You will also have to make sure you don't free the old > machine code while there are still functions executing in it. An easy > (yet inefficient) way to deal with this is to update a refcount on > function entry/exit.Well said :) -eric
Xin Tong Utoronto
2011-Apr-03 19:01 UTC
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Fri, Apr 1, 2011 at 1:26 PM, Eric Christopher <echristo at apple.com> wrote:> > On Apr 1, 2011, at 9:38 AM, Reid Kleckner wrote: > > > On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at apple.com> > wrote: > >>> > >>> > >>> Then we would always have the location of the br B instruction in A, as > it is pushed onto the stack or saved in link register when A calls B. > >>> > >> > >> Right, unless you wanted to go with direct calls in the JIT. I don't > know that inspecting a running program's stack for return values while > compiling on a separate thread is sane :) > >> > >> That said, the adaptive compilation strategy can always enforce the use > of a stub for calls into jitted functions. > > > > I think you said what I was going to say, but here's how I see it: > > > > getPointerToFunction always returns the address of the stub, so any > > indirect calls to the function hit the stub. The stub will attempt to > > backpatch the callsite, and should fail if it is a) outside the JIT or > > b) an indirect call. Indirect calls will always go through the stub. > > Direct calls can be backpatched. > > > > Alternatively, everything would go through the stub. > > > > Finally, you have to be careful about the memory model of the > > architecture you're dealing with if you care about threads. On x86, > > if you can align the operand of the call instruction, you can do an > > atomic update. You will also have to make sure you don't free the old > > machine code while there are still functions executing in it. An easy > > (yet inefficient) way to deal with this is to update a refcount on > > function entry/exit. > > Another way to do the patching is to first atomically inserted a self-loopjump -2 atomically (jump -2 takes 2 bytes and 2 bytes writing is atomic on x86 ) into the old branch address on x86 such that it stops all threads reaching this point. copy in the new compiled function address. and then re-patch the jump -2 with the correct binary. Well said :)> > -eric >-- Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110403/7ea033f6/attachment.html>
Maybe Matching Threads
- [LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
- [LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
- [LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
- [LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
- [LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler