[LLVMdev] New JIT APIs

[Philip Reames]

On 01/14/2015 11:49 AM, Lang Hames wrote:
>
>       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.
I don't have the code in front of my right now, but I'll take a look 
later today and try to summarize clearly.
>
> 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.
>
>>     (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/7f0c7727/attachment.html>