[LLVMdev] New JIT APIs

[David Blaikie]

On Wed, Jan 14, 2015 at 11:49 AM, Lang Hames <lhames at gmail.com> wrote:

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

Why not? We did work to remove the legacy JIT in favor of MCJIT for the
usual reasons (less code/maintenance burden/etc) - it'd seem unfortunate to
then go back to maintaining two JITs again.

You mention the intent to provide a superset of MCJIT's behavior, at which
point it seems it'd be preferable to kill of MCJIT in favor of ORC (heck,
we killed of the legacy JIT before MCJIT had feature parity).


>
>
>>   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.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/244279ac/attachment.html>