<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">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><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 class="HOEnZb"><font color="#888888"><div>- Paweł</div></font></span></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>