<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 14, 2015 at 11:49 AM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Philip,<div><br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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?</div></blockquote><div><br></div></span><div>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.</div></div></div></div></div></blockquote><div><br>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.<br><br>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).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> 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.) <br></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
I really like the idea of having a low level JIT interface for
advanced users and an easy starting point for folks getting
started. </div></blockquote><div><br></div></span><div>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.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div><blockquote type="cite">
<div dir="ltr">
<div style="font-size:13px">(3)</div>
<div style="font-size:13px">Q. Why "addModuleSet" rather than
"addModule"?</div>
<div style="font-size:13px">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.</div>
</div>
</blockquote></div></div>
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. <span><br></span></div></blockquote><div><br></div></span><div>Sure. This problem should be tackled in the wrappers around the components, rather than the components themselves. See MCJITReplacement::addModule for an example. </div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span><blockquote type="cite"><div dir="ltr"><div style="font-size:13px">
</div>
<div style="font-size:13px">(4)</div>
<div style="font-size:13px">Q. What happened to "finalize"?</div>
<div style="font-size:13px">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.</div>
</div>
</blockquote></span>
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. <br></div></blockquote><div><br></div></span><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Lang.</div></font></span></div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>