[PATCH] New JIT APIs (ORC)

Lang Hames lhames at gmail.com
Thu Jan 22 11:40:34 PST 2015


Hi Rafael,

The callback code is some of the nastiest stuff in the current prototype.
I'd love to see it cleaned up.

I think there may be scope to re-use the GOT/PLT for jumping back in to the
JIT, but we'll need some new RuntimeDyld API first: The JIT would need to
be able to find and modify GOT entries.

Cheers,
Lang.

On Thu, Jan 22, 2015 at 8:51 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> > Questions and comments welcome.
>
> The way lazy compilation is implemented looks odd. My understanding is
> that the IR is patched to turn "call @foo" into a load + call into the
> JIT.
>
> Why no just make @foo a declaration and compile with -fPIC? That will
> produce a 'call foo at plt' in the produced .o file. With that, our
> "dynamic linker" can create a got and a plt. The plt loads the got and
> jumps to it. The initial value in the GOT can be to just jump to
> MCJIT. Following calls will be direct.
>
> So the PLT the our dynamic linker creates could look like
>
> jmpq *got_entry
> movq some_jit_created_id_of_the_function $RDI ; The got_entry
> initially points here
> jmpq some_mcjit_funcion
>
> Then some_mcjit_funcion can extract the IR out to a new module,
> codegen that and set the got_entry.
>
> This also has the advantage of not requiring a large code model, even
> if the two functions are put far apart.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150122/cf78e90f/attachment.html>


More information about the llvm-commits mailing list