[LLVMdev] mcjit

[Kaylor, Andrew]

Hi Pawel,

Everthing Verena said is an accurate reflection of the current LLVM trunk implementation of MCJIT.  However, I have a couple of additional comments.

>* 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'm hoping to get a solution into LLVM trunk soon to enable ELF on Windows.  It's not at the top of the priority list, but it's one of the things I proposed in a recent list of MCJIT work and I expect to reopen the discussion to seek a general solution in the next couple of weeks.


>* 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).

I'll be submitting a patch very soon to delay code generation until getPointerToFunction is called.


> * 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.

It is possible to create one MCJIT engine per module and cross-link between the modules.  I'd need to review some code to give you details but I know that it works.  The MCJIT engine uses a memory manager to look up unresolved functions (that is, function that are external to the single module passed to an instance of MCJIT).


I hope that as someone using the MCJIT feature you will participate in the discussion of the MCJIT enhancements as it unfolds.  You can find the start of the discussion here:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/052022.html

-Andy


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
>>>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev