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>
Eric Christopher
2011-Apr-03 19:11 UTC
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Apr 3, 2011, at 12:01 PM, Xin Tong Utoronto wrote:> Another way to do the patching is to first atomically inserted a self-loop jump -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.Heh. That'd work on x86 at least. I don't know about other architectures. -eric
Owen Anderson
2011-Apr-04 17:49 UTC
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Apr 3, 2011, at 12:11 PM, Eric Christopher wrote:> <snip conversation about call patching>It seems to me that there's a general feature here that LLVM is lacking, that would be useful in a number of JIT-compilation contexts, namely the ability to mark certain instructions (direct calls, perhaps branches too) as back-patchable. The thing that stands out to me is that back-patching a call or branch in a JIT'd program is very much like relocation resolution that a dynamic linker does at launch time for a statically compiled program. It seems like it might be possible to build on top of the runtime-dyld work that Jim has been doing for the MC-JIT to facilitate this. Here's the idea: Suppose we had a means of tagging certain calls (and maybe branches) as explicitly requiring relocations. Any back-patchable call would have a relocation in the generated code, and the MC-JIT would be aware of the location and type of the relocations, and rt-dyld would handle the upfront resolution. Backpatching, then, is just a matter of updating the resolution for a given symbol, and asking rt-dyld to re-link the executable code. Thoughts? --Owen
Seemingly Similar 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