[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC

[Jim Grosbach]

On Nov 26, 2012, at 9:04 AM, Albert Graef <Dr.Graef at t-online.de> wrote:

> On 11/25/2012 11:16 AM, Benjamin Kramer wrote:
>> It's possible to coexist, but increases the maintenance burden.
> 
> Ok, I understand.
> 
>> I can understand your concerns and I wouldn't have proposed this change if the old JIT for ARM and PPC actually worked. When running LLVM's regression tests on a ARM or PPC64 host most of the JIT tests simply fail. That's why the regression tests now run MCJIT by default on those platforms (and tests pass), which won't make the situation any better for the old JIT.
> 
> Indeed. Well, I've had reports that people got Pure to run on ARM at
> some point, not sure how well it worked, though. ;-) I'm just beginning
> to dabble with ARM myself as I'd like to port Pure to Android. Well, I
> guess that we'll just continue to use older LLVM versions on ARM for the
> time being, if I can get it to work at all with the old JIT. Who knows,
> Pure is a rather special language which doesn't utilize all cpu
> features, maybe the old JIT supports ARM well enough to run Pure code
> even though it fails many of the tests.
> 
>> I know that you rely on lazy compilation in your project and the old x86 JIT isn't going away until that is implemented in the MCJIT. However, it requires that someone makes the investment to port it over, not sure what exactly is needed for this.
> 
> Is anyone looking into this already? It seems that lazy compilation (or
> any kind of incremental compilation; I don't really care as long as I
> can swap out the bodies of single functions and the JIT is fast enough)
> is the one critical feature that keeps us from using MCJIT for dynamic
> language implementations. So it would be nice if someone who knows the
> JIT code inside out could have a look at that. I know I'm asking too
> much but I'd really like to give MCJIT a try rather sooner than later.
> ;-) I'm afraid that I don't know enough about the lowlevel parts of the
> JIT to have a go at it myself, but I could certainly help testing this
> if someone else implements it.
> 

The MCJIT will require a bit of change to the model clients use. Specifically, everything in the MCJIT is at the Module level of granularity, and that will include lazy compilation. So if you want to compile a function at a time, you'll need to create a separate Module for each function. Relatedly, a module is effectively immutable once it's been passed to the MCJIT. You can't keep adding new definitions to the module afterwards, for example.

The exact details of lazy compilation are a bit vague right now, but generally speaking, it'll work similarly to the old code, just with compilation being a module at a time.

-Jim



> Albert
> 
> -- 
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev