[LLVMdev] MCJIT and Lazy Compilation

Andrew Sorensen digegoo at gmail.com
Fri Feb 15 22:55:57 PST 2013


Hey Sean,

I'm sure Andy.K will have some thoughts on this but
I don't imagine any major API changes being required.
The changes that I have been making are really very
minor, all the work is already done.

However I can imagine some client side fallout due to the
multi-module nature of the proposed solution. The client
side problem being that I imagine that many people are
using a single monolithic module for various bookkeeping
purposes on the client side - function signature lookups
for example.

One slightly dubious way around this might be to have a
monolithic module 'just for bookkeeping' which is managed
persistently in 'parallel' to the individual object modules -
which I'm currently throwing away after each "compile".
Ultimately though it's probably better for the client to manage
this kind of bookkeeping outside of LLVM anyway?

Another solution might be to add some additional meta-data
to the runtime memory manager - although I can't imagine
people liking this idea very much as it would be a fairly
gross violation of the current mem-mgr interface.

Anyway, I'm sure that Andy will have a much better handle
on what solutions might or might not be appropriate.

Cheers,
Andrew.


On Sat, Feb 16, 2013 at 7:38 AM, Sean Silva <silvas at purdue.edu> wrote:

> This is great news!
>
> Does it seem like it will be possible to develop an actual coherent
> API that we can point people to? (e.g. for old JIT users to migrate
> to). Or is this solution best packaged as pure documentation "this is
> how you accomplish this; adapt the ideas to your use case"?
>
> I would prefer having an actual API for clients to use. We have no
> shortage of people waiting for MCJIT lazy compilation, so it probably
> won't be hard to collect feedback to iterate the API design.
>
> -- Sean Silva
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130216/8ee9b45a/attachment.html>


More information about the llvm-dev mailing list