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.
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).
* Make sure you include MCJIT.h and link in MCJIT.lib, otherwise (even if you set setUseMCJIT(true)) you won't be using MCJIT.
* 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.
* 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,
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.
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: