llvm dev - Apr 2011 - [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-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 :)
>
> -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>

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

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