[PATCH][llvm-c] Expose MC JIT

Amara Emerson amara.emerson at arm.com
Tue Apr 23 03:10:09 PDT 2013


Agreed here about getting at least some default "do the right thing" cache
management into core LLVM. This is such an easy issue to miss, especially
for people who don't know about the architectural memory model intricacies
and just want the API to do what it says. So much so, that our own
"reference" client, lli, was silently failing to handle it correctly until a
few months ago.

 

At the same time we need an interface that gives clients fine grain control
over memory management and page permissions etc. I don't like the ownership
model as it currently stands, with ExecutionEngine eagerly destroying the
memory manager object. This makes people write ugly workarounds to maintain
control over their JITed code while trying to get around the lack of
multiple modules support. IMO, the JIT compiler and memory manager are
related, but mostly orthogonal, components.

 

Amara

 

 

From: llvm-commits-bounces at cs.uiuc.edu
[mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of David Tweed
Sent: 23 April 2013 09:06
To: 'Filip Pizlo'; Kaylor, Andrew
Cc: llvm-commits at cs.uiuc.edu
Subject: RE: [PATCH][llvm-c] Expose MC JIT

 

Hi,

 

It's great that you're doing high-quality work on getting MC-JIT into a much
better shape!

 

| More broadly, getting MCJIT into a better shape is on my critical path, as
well.  See: https://bugs.webkit.org/show_bug.cgi?id=112840.  I'd like to
help out with the de-sloppiness-ifying of it, so I'd like to understand
better what the end goal is.  I

|already know that I want to control memory management, cache management,
and page permissions myself as a client, and preferably I want to accomplish
this by supplying my own RuntimeDyld (or JITMemoryManager).  I also know
that I'll want to

|improve error tolerance - for example in case of memory allocation failure
(honestly, I haven't investigated this much, so this may already be
supported - I just don't see how through the API).  So, I'm particularly
interesting in seeing how to get the

|MCJIT into a great shape while supporting both the currently-envisioned use
cases in LLVM and its other clients, and also the way that WebKit will use
it!  This should be fun. :-)

 

Can I just ask why you want to control cache management and page permissions
within your client code? (This is a genuine question: I don't quite see what
it gets you, but it'd be interesting to know.) One of my worries about
delegating cache management is that it can be a source of very intermittent
bugs: if you don't cache invalidate on the transition from data to code on
ARM, 99% of the time everything works... I can't at the moment see the
advantage of not delegating that to a core part of LLVM that "knows what
it's doing better than I do".

 

Cheers,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130423/dfa59274/attachment.html>


More information about the llvm-commits mailing list