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