[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
Eric Christopher
echristo at apple.com
Fri Apr 1 10:26:28 PDT 2011
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
More information about the llvm-dev
mailing list