[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC

[Manny Ko]

I know the old JIT pretty well but have only used the MCJIT from the client side. Most of my experience is on the x86backend though.  

Another critical feature missing from MCJIT is the JITEventListener.  This is usually for supporting debuggers and profiling tools.

Ciao.

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Albert Graef
Sent: Monday, November 26, 2012 9:05 AM
To: Benjamin Kramer
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC

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.

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