llvm dev - Apr 2011 - [LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler

On Thu, Mar 31, 2011 at 11:07 PM, Eric Christopher <echristo at
apple.com>wrote:
> >
> >
> > No we will always have control over where the parent calls the
functions
> that we are recompiling. As explained in the example below
> >
> > Original Code
> >
> > Binary for A:         Binary for B:
> >
> > ...                         ...
> > ...                         ...
> > br B                      ...
> > ...                         ...
> > ...
> >
> > After B is recompiled, we patch the entry of B with br helper
> >
> > Binary for A:         Binary for B:        Binary for Recompiled B
> > ...                        br helper              ...
> > ...                        ...                        ...
> > br B                     ...                        ...
> > ...
> > ...
> >
> >
> > now when the parent A calls B, B branches to the helper, we will get
the
> address of br B from the return address pushed onto the
> > stack or saved in the link register. The helper then patches the
callsite
> in A
> >
> > After Patching
> >
> > Binary for A:               Binary for B:        Binary for Recompiled
B
> > ...                               br helper             ...
> > ...                               ...                       ...
> > br Recompiled B          ...                       ...
> > ...
> > ...
> >
>
> Your helper is what I'm calling a stub (and what they're called in
the jit
> at the moment).
>
> -eric
>
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.



-- 
Kind Regards

Xin Tong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110331/a9b58037/attachment.html>

> 
> 
> 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.

-eric

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