[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler

Reid Kleckner reid.kleckner at gmail.com
Fri Apr 1 09:38:39 PDT 2011

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.


More information about the llvm-dev mailing list