[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
Xin Tong Utoronto
x.tong at utoronto.ca
Sun Apr 3 12:01:14 PDT 2011
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>
> >>> 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-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.
Well said :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev