[LLVMdev] Thoughts about ExecutionEngine/MCJIT interface

[Hayden Livingston]

Another question: Lang, when do you think it'll be ok to move it to the C
Bindings?

On Fri, Mar 13, 2015 at 6:39 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Pawel,
>
> I agree. ExecutionEngine, in its current form, is unhelpful. I'd be in
> favor of cutting the common interface back to something like:
>
> class ExecutionEngine {
> public:
>   virtual void addModule(std::unique_ptr<Module> M) = 0;
>   virtual void* getGlobalValueAddress(const GlobalValue *GV) = 0;
>   virtual GenericValue runFunction(const Function *F,
>                                    const std::vector<GenericValue> &Args)
> = 0;
> };
>
> That's the obvious common functionality that both the interpreter and
> MCJIT provide. Beyond that I think things get pretty implementation
> specific.
>
> 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.
>
> Cheers,
> Lang.
>
>
> On Sat, Mar 14, 2015 at 4:57 AM, Paweł Bylica <chfast at gmail.com> wrote:
>
>> Hi,
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> My propositions / discussion starting points:
>>
>>    1. Expose MCJIT header in public API. It will allow users to cast
>>    ExecutionEngine instance to MCJIT instance.
>>    2. Separate Interpreter and MCJIT interfaces and add them to API.
>>    ExecutionEngine can still be a base class for real common part (like module
>>    list).
>>    3. Try to alter ExecutionEngine interface to unify common Interpreter
>>    and MCJIT features. Is it possible to have one getFunction() method?
>>
>> - Paweł
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150313/7afa35ff/attachment.html>