<div dir="ltr">Hi Pawel,<div><br></div><div>I believe that an early (working) version of Orc is in the 3.6 release, and work on Orc is continuing on trunk.</div><div><br></div><div>The MCJIT API (or at least the ExecutionEngine API) will stay with us for some time, but hopefully only the API. I am hoping that the MCJIT class itself can be deprecated in the future in favor of the OrcMCJITReplacement class. Given that, I'd rather not expose MCJIT directly: Any work we do there will have to be duplicated in OrcMCJITReplacement if everything goes to plan.</div><div><br></div><div>Orc *should* be a good fit for any MCJIT client: It was designed with MCJIT's use-cases in mind, and built on the same conceptual framework (i.e. replicating the static pipeline by linking object files in memory). It's aim is almost exactly what you've described: To tidy MCJIT up and expose the internals so that people can add new features.</div><div><br></div><div>I'd be interested to hear how you go porting your project to Orc, and I would be happy to help out where I can. What features of MCJIT are you using now? And what do you want to add? I'd suggest checking out the Orc/Kaleidoscope tutorials (see llvm/examples/Kaleidoscope/Orc/*) and the OrcMCJITReplacement class (see llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.*) to get an idea of what features are available now. It sounds like you'll want to add to this, but then that's the purpose of these new APIs.</div><div><br></div><div>As a sales pitch for Orc, I've included the definition of the initial JIT from the Orc/Kaleidoscope tutorials below. As you can see, you can get a functioning "custom" JIT up and running with a page of code. This basic JIT just lets you throw LLVM modules at it and execute functions from them. Starting from this point, with 149 lines worth of changes*, you can build a JIT that lazily compiles functions from ASTs on first call (no need to even IRGen up front).</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div><div><div>* As reported by:</div><div><font face="monospace, monospace">diff examples/Kaleidoscope/Orc/{initial,fully_lazy}/toy.cpp | wc -l</font></div></div><div><font face="monospace, monospace"><br></font></div><font face="monospace, monospace">class KaleidoscopeJIT {<br>public:<br> typedef ObjectLinkingLayer<> ObjLayerT;<br> typedef IRCompileLayer<ObjLayerT> CompileLayerT;<br> typedef CompileLayerT::ModuleSetHandleT ModuleHandleT;<br><br> KaleidoscopeJIT(TargetMachine &TM)<br> : Mang(TM.getDataLayout()),<br> CompileLayer(ObjectLayer, SimpleCompiler(TM)) {}<br><br> std::string mangle(const std::string &Name) {<br> std::string MangledName;<br> {<br> raw_string_ostream MangledNameStream(MangledName);<br> Mang.getNameWithPrefix(MangledNameStream, Name);<br> }<br> return MangledName;<br> }<br><br> ModuleHandleT addModule(std::unique_ptr<Module> M) {<br> auto MM = createLookasideRTDyldMM<SectionMemoryManager>(<br> [&](const std::string &Name) {<br> return findSymbol(Name).getAddress();<br> },<br> [](const std::string &S) { return 0; } );<br><br> return CompileLayer.addModuleSet(singletonSet(std::move(M)), std::move(MM));<br> }<br><br> void removeModule(ModuleHandleT H) { CompileLayer.removeModuleSet(H); }<br><br> JITSymbol findSymbol(const std::string &Name) {<br> return CompileLayer.findSymbol(Name, true);<br> }<br><br> JITSymbol findUnmangledSymbol(const std::string Name) {<br> return findSymbol(mangle(Name));<br> }<br><br>private:<br> Mangler Mang;<br> ObjLayerT ObjectLayer;<br> CompileLayerT CompileLayer;<br>};</font></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 1:28 AM, Paweł Bylica <span dir="ltr"><<a href="mailto:chfast@gmail.com" target="_blank">chfast@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 Lang,<div><br></div><div>I know that Orc JIT is somewhere around the corner, but haven't had time to check it out. Is it available in 3.6 release? If yes I will try to port my project to the new API and share experiences.</div><div><br></div><div>However, MCJIT API will stay with us for some time. I would like to add some improvements to it if we agreed in what direction we would like to go. Personally I would like to expose whole MCJIT class and reduce ExecutionEngine interface.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">- Paweł</font></span><div><div class="h5"><br><br><div class="gmail_quote">On Sat, Mar 14, 2015 at 2:39 AM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Pawel,<div><br></div><div>I agree. ExecutionEngine, in its current form, is unhelpful. I'd be in favor of cutting the common interface back to something like:</div><div><br></div><div><font face="monospace, monospace">class ExecutionEngine {</font></div><div><font face="monospace, monospace">public:</font></div><div><font face="monospace, monospace"> virtual void addModule(std::unique_ptr<Module> M) = 0;</font></div><div><font face="monospace, monospace"> virtual void* getGlobalValueAddress(const GlobalValue *GV) = 0;</font></div><div><font face="monospace, monospace"> virtual GenericValue runFunction(const Function *F,</font></div><div><font face="monospace, monospace"> const std::vector<GenericValue> &Args) = 0;</font></div><div><font face="monospace, monospace">};</font></div><div><br></div><div>That's the obvious common functionality that both the interpreter and MCJIT provide. Beyond that I think things get pretty implementation specific.</div><div><br></div><div>For what it's worth, this is an issue that I'm trying to address with the new Orc JIT APIs. Those expose the internals directly to give you more control. If you don't want to be able to switch the underlying execution-engine, they may be a good fit for your use-case.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 14, 2015 at 4:57 AM, Paweł Bylica <span dir="ltr"><<a href="mailto:chfast@gmail.com" target="_blank">chfast@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. </div><div><br></div><div>Personally, I'm using MCJIT and wish to have access to some methods not available from ExecutionEngine. E.g. I would like to use getSymbolAddress() instead of getFunctionAddress() sometimes as getFunctionAddress() do some additional work what I'm sure has be done already.</div><div><br></div><div>Maybe it's time face the truth that Interpreter and MCJIT based solutions are not so similar and different interfaces are needed. Or maybe some unification is possible?</div><div><br></div><div>My propositions / discussion starting points:</div><div><ol><li>Expose MCJIT header in public API. It will allow users to cast ExecutionEngine instance to MCJIT instance.</li><li>Separate Interpreter and MCJIT interfaces and add them to API. ExecutionEngine can still be a base class for real common part (like module list).</li><li>Try to alter ExecutionEngine interface to unify common Interpreter and MCJIT features. Is it possible to have one getFunction() method?</li></ol><span><font color="#888888"><div>- Paweł</div></font></span></div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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>
</blockquote></div></div></div></div></div>
</blockquote></div><br></div>