[LLVMdev] mcjit (original) (raw)

Kaylor, Andrew andrew.kaylor at intel.com
Tue Jul 31 10:25:33 PDT 2012

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

More information about the llvm-dev mailing list