[prev in list] [next in list] [prev in thread] [next in thread] 

List:       llvm-dev
Subject:    Re: [LLVMdev] mcjit
From:       "Kaylor, Andrew" <andrew.kaylor () intel ! com>
Date:       2012-07-31 17:25:33
Message-ID: 0983E6C011D2DC4188F8761B533492DE077CCF66 () ORSMSX105 ! amr ! corp ! intel ! com
[Download RAW message or body]

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@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


[prev in list] [next in list] [prev in thread] [next in thread]