[PATCH][llvm-c] Expose MC JIT

[David Tweed]

Hi,

 

|The fact that we want to do cache/page management ourselves is a
consequence of us having our own memory manager and our own JITs.  The fact
that we will continue to handle cache/page invalidation ourselves is a
consequence of us wanting to kee

| our memory manager even as we use LLVM for our top-tier JIT, because we
believe that it is better-suited to our needs than the memory managers that
the LLVM provides.

 

| I can give you a more detailed answer on why we would like to keep this
memory manager - but I figured I'd ask for clarification before writing that
up.

 

So it sounds like you're saying: the LLVM code co-exists with a wider set of
software and to work best across all of these a different memory manager to
LLVM's. That makes sense. I was worried that there was some reason why the
LLVM stuff was fundamentally misdesigned for JITing, which would suggest
that misdesign ought to be considered.

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

 

| We've had JITs in WebKit for X86 (32 and 64), ARM (traditional and
thumb2), and other architectures for years.  I'm pretty sure we know how to
do this.

 

Sorry, I tried to phrase the (as I said, genuine) question as
non-confrontationally as I could; I wasn't in any way implying that "serious
JIT developers" (such as the WebKit guys yourselves) know exactly when you
need to do cache invalidation. I'm thinking more in terms of smaller
projects which just want to use LLVM rather than become JIT experts, such as
languages using LLVM to JIT code in a REPL (which IMO is one of the most
exciting things LLVM has enabled): I _think_ I understand what needs to be
done when for ARM, but I couldn't tell you what needs to be done when on a
MIPs or PPC CPU. But it sounds like we've been talking at cross-purposes: I
was worried if it became the clients responsibility to implement code that
did cache management, but from Amara's responses it sounds like it's just a
route you can use if you want to, but there will be an official part of LLVM
that understands what to do when on all the supported architectures. So my
worry is groundless.  (Also in case I'm being a bit unclear: I can see that
it's a modularity issue to have teh ExectuionEngine doing so much stuff for
other objects in LLVM and refactoring it so something else deals with these
issues would be a good thing, I'd just really like there to be some piece of
rock-solid reliable piece of LLVM code that clients can use that knows what
to do when for every supported target.)

 

Cheers,

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