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

On 25.11.2012, at 00:34, Albert Graef <Dr.Graef at t-online.de> wrote:
> On 11/24/2012 05:06 PM, Benjamin Kramer wrote:
>> I'm proposing to remove the JIT code emitters for the ARM and PPC
targets now so it's no longer holding back the development of the MC parts
for those backends.
> 
> Why is this holding back MCJIT development? If the old JIT with the x86
> backend can coexist with MCJIT, why isn't this possible with the other
> backends?
It's possible to coexist, but increases the maintenance burden. The old JIT
basically contains a less maintained copy of the MC code emitter, which has to
be updated if there are significant changes to the instruction definitions. New
instructions often don't get added to the old JIT emitter, that's why
AVX support in the old JIT on x86 is flaky at best. It also keeps people from
restructuring parts of the backend, e.g. the ARM backend contains a number of
hacks to keep the old JIT machine code emitter working.
> I have mixed feelings about this. I understand that you want to get rid
> of cruft asap, but removing the old JIT or any significant part of it
> seems premature at this point. MCJIT still has to prove itself. I've
> really been looking forward to give MCJIT a try since it was first
> announced, but if it still isn't a full replacement for the old JIT yet
> then *that* is what needs to be worked on first IMHO.
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.

It's also important to know that the MCJIT is comparatively small compared
to the old JIT in terms of specific code needed for it. Most of the target
specific bits are shared with the static compiler now, which is extremely well
tested and probably contains less bugs now than the old JIT machine code, which
has matured over a long time.

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.

- Ben

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

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 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