[LLVMdev] New JIT APIs

[Lang Hames]

Hi Philip,

In terms of the overall idea, I like what your proposing.  However, I want
> to be very clear: you are not planning on removing any functionality from
> the existing (fairly low level) MCJIT interface right?
>

To confirm - I have no plans to remove MCJIT. I don't want to change any
behavior for existing clients. The new stuff is opt-in.


>   We've built our own infrastructure around that and require a few
> features it doesn't sounds like you're planning on supporting in the new
> abstractions.  (The biggest one is that we "install" code into a different
> location from where it was compiled.)
>

Can you clarify what you mean by "install" here? As it stands in the patch,
Orc already supports cross-target and out-of-process JITing. The
ObjectLinkingLayer exposes the mapSectionAddress call for mapping sections
to new locations, and the MCJITReplacement demo passes all remote-jitting
regression tests on Darwin.

The intent is that Orc should eventually provide a superset of the
functionality provided by MCJIT, but with the various features broken out
into separate components. I'd be interested to hear about anything that's
missing so that I can, if possible, add support for it.


> I really like the idea of having a low level JIT interface for advanced
> users and an easy starting point for folks getting started.
>

Ideally I would like Orc to cover the whole spectrum. I'm hoping we can
quickly advance to the point where new JIT developers would use Orc by
default, rather than MCJIT, and not miss any features. I expect advanced
users will want to compose their stacks directly, while beginners would
take some common configuration off the shelf. Once these patches are in
tree I'm planning to add a basic lazy-jitting stack for Kaleidoscope that
beginners could use as a starting point.

 (3)
> Q. Why "addModuleSet" rather than "addModule"?
> A. Allowing multiple modules to be passed around together allows layers
> lower in the stack to perform interesting optimizations. E.g. direct calls
> between objects that are allocated sufficiently close in memory. To add a
> single Module you just add a single-element set.
>
> Please add a utility function for a single Module if you haven't already.
> For a method based JIT use case, multiple Modules just aren't that useful.
>

Sure. This problem should be tackled in the wrappers around the components,
rather than the components themselves. See MCJITReplacement::addModule for
an example.


>  (4)
> Q. What happened to "finalize"?
> A. In the Orc APIs, getSymbolAddress automatically finalizes as necessary
> before returning addresses to the client. When you get an address back from
> getSymbolAddress, that address is ready to call.
>
> As long as this is true for the high level API and *not* the low level one
> (as is true today), this seems fine.  I don't really like the finalize
> mechanism we have, but we do need a mechanism to get at the code before
> relocations have been applied.
>

You should still be able to intercept events to access memory before
finalization. If you can be more specific about your use-case I'd be keen
to figure out if/how it could be supported in Orc.

- Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/bdb366a1/attachment.html>