llvm dev - Nov 2012 - [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC

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

On Mon, Nov 26, 2012 at 9:18 AM, Manny Ko <Manny.Ko at imgtec.com>
wrote:
> 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.

What makes you say it is missing?

Eli

Sorry for speaking too soon. It is missing from 3.2 which is the version I have
been using.  If it is already implemented than it is very good news.

Thanks.

-----Original Message-----
From: Eli Bendersky [mailto:eliben at google.com] 
Sent: Monday, November 26, 2012 9:25 AM
To: Manny Ko
Cc: Albert Graef; Benjamin Kramer; LLVM Developers Mailing List
Subject: Re: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC

On Mon, Nov 26, 2012 at 9:18 AM, Manny Ko <Manny.Ko at imgtec.com>
wrote:
> 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.

What makes you say it is missing?

Eli