[LLVMdev] mcjit

[Paweł Bylica]

Hi Verena,

Thanks very much for your response.

On Tue, Jul 31, 2012 at 4:52 PM, Verena Beckham <verena at codeplay.com> wrote:
> Hi Pawel,
>
> Some of the issues I have come across (from memory!) are
>
> * MCJIT doesn't work on Windows, because it doesn't support COFF. If you
> want to use it on Windows you have to either target Mach-O (not clear
> whether that will work in general) or ELF (need to get a patch from Intel to
> be able to use this).
I switched to ELF format. Works fine.
>
> * Make sure you include MCJIT.h and link in MCJIT.lib, otherwise (even if
> you set setUseMCJIT(true)) you won't be using MCJIT.
I've figured it out. That's really strange way of "enabling" MCJIT.
There should be a warning that MCJIT is not used even though
"use-mcjit" flag is set.
>
> * In JIT codegen happens when you call getPointerToFunction. In MCJIT this
> happens when you create the ExecutionEngine. So you cannot have any code
> generation after that. Creation of the ExecutionEngine should be the last
> thing you do (before calling getPointerToFunction).
>
> * MCJIT supports only a single Module. You need all your code to be
> self-contained, If you call functions in other Modules there will be a
> ("liker" type) error.

That's the biggest problem. I'm using the old JIT with
LazyFunctionCreator which allows me to load necessary modules on
demand. It does not work perfectly even there (it will not allow you
to load global variables on demand). Maybe I will first try "load
everything and run" solution with MCJIT to check if it works. There
are many parts of the MCJIT that expect to have everything loaded so
implementing lazy compilation is not so simple.

>
> * Because only one Module is supported the function addModule doesn't do
> anything useful. You need to create a new ExecutionEngine for each module.
>
> I'm working with LLVM 3.1, but I don't think much has changed in trunk.
> Hope this helps,
>
>  Verena
>
>
>
> On 31/07/2012 11:16, Paweł Bylica wrote:
>>
>> Thu Jul 12 03:42:12 CDT 2012, Verena Beckham verena at codeplay.com :
>>>
>>> I would not say it is trivial, having done it myself.
>>>
>>> MCJIT also doesn't support multiple modules, and it does not do JITing
>>> on demand, instead, it does all of it at the same time in the
>>> constructor (unless that is what you call "not lazy").
>>> So depending on how you've written your code there is some significant
>>> reshuffling to do to, to move the creation of the ExecutionEngine to the
>>> end, and possibly add ExecutionEngines.
>>>
>>>    Verena
>>
>>
>> Can you share any information how to do it?
>>
>>>
>>>
>>> On 11/07/2012 17:14, Jim Grosbach wrote:
>>>>
>>>>
>>>> On Jul 11, 2012, at 6:04 AM, Benjamin Kramer wrote:
>>>>
>>>>>
>>>>> On 11.07.2012, at 14:39, Reed Kotler <rkotler at mips.com> wrote:
>>>>>
>>>>>> Does anyone know which projects rely on mcjit?
>>>>>>
>>>>>> There is the oldjit too; it's still being used?
>>>>>
>>>>>
>>>>> The most prominent user of the MC JIT is probably LLDB.
>>>>>
>>>>> The only issue with MCJIT I know of is the lack of windows support, and
>>>>> I expect oldjit to go away once that is sorted out. Switching between the
>>>>> JIT implementations is really trivial and transparent, if you don't have to
>>>>> support windows it's worth a try.
>>>>>
>>>>
>>>> MCJIT also doesn't yet support lazy compilation. That's not a big
>>>> problem to add; it's just not been necessary for anyone yet.
>>>>
>>>> -Jim
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>