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

While the MCJIT doesn't cover all of the features the old JIT had, it has
the huge advantage of actually producing working results on ARM and PPC64. The
old JIT for non-x86 has bit-rotted a lot, to the point of crashing even for
simple examples.

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. The JITInfo parts can stay, they may be useful if someone wants to
implement lazy compilation on top of MCJIT. It would become dead code though.

The MCJIT for PPC only supports PPC64 currently. However, PPC32 old JIT never
worked for non-darwin platforms and seems to be broken even there at the moment.

Any objections? x86 will stay around for a while, it's reasonably well
maintained and has many users.

- Ben

Thanks for your information. So, do you think it's better working with
MCJIT instead of JIT specially for ARM platforms? I'm going to work on .bc
files of some benchmarks for ARM platform. And, I decided to work with the
JIT. Now, you proposed working with MCJIT. Could I get all the benefits of
JIT in MCJIT as well?

Regards
Negar

On Sat, Nov 24, 2012 at 4:06 PM, Benjamin Kramer <benny.kra at
gmail.com>wrote:
> While the MCJIT doesn't cover all of the features the old JIT had, it
has
> the huge advantage of actually producing working results on ARM and PPC64.
> The old JIT for non-x86 has bit-rotted a lot, to the point of crashing even
> for simple examples.
>
> 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. The JITInfo parts can stay, they may be useful if someone
> wants to implement lazy compilation on top of MCJIT. It would become dead
> code though.
>
> The MCJIT for PPC only supports PPC64 currently. However, PPC32 old JIT
> never worked for non-darwin platforms and seems to be broken even there at
> the moment.
>
> Any objections? x86 will stay around for a while, it's reasonably well
> maintained and has many users.
>
> - Ben
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121124/721144ea/attachment.html>

On 24.11.2012, at 17:53, Negar Mir <nmiralaei at gmail.com> wrote:
> Thanks for your information. So, do you think it's better working with
MCJIT instead of JIT specially for ARM platforms? I'm going to work on .bc
files of some benchmarks for ARM platform. And, I decided to work with the JIT.
Now, you proposed working with MCJIT. Could I get all the benefits of JIT in
MCJIT as well?
The big missing feature from the MC JIT is lazy compilation, so it will compile
all your code upfront instead of on a per-function basis. You still get all
other benefits of the JIT. You can also use the old JIT for x86 and MCJIT on
other targets with no big issues.

Did you try to use the old JIT on ARM yet? As far as I know it doesn't work
at all, so MCJIT is a strict improvement.

- Ben
> 
> Regards
> Negar 
> 
> On Sat, Nov 24, 2012 at 4:06 PM, Benjamin Kramer <benny.kra at
gmail.com> wrote:
> While the MCJIT doesn't cover all of the features the old JIT had, it
has the huge advantage of actually producing working results on ARM and PPC64.
The old JIT for non-x86 has bit-rotted a lot, to the point of crashing even for
simple examples.
> 
> 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. The JITInfo parts can stay, they may be useful if someone
wants to implement lazy compilation on top of MCJIT. It would become dead code
though.
> 
> The MCJIT for PPC only supports PPC64 currently. However, PPC32 old JIT
never worked for non-darwin platforms and seems to be broken even there at the
moment.
> 
> Any objections? x86 will stay around for a while, it's reasonably well
maintained and has many users.
> 
> - Ben
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Sounds great to me, please remove the dead jit info code as well though -
someone can pull them out of svn if useful in the future.

-Chris

On Nov 24, 2012, at 8:06 AM, Benjamin Kramer <benny.kra at gmail.com>
wrote:
> While the MCJIT doesn't cover all of the features the old JIT had, it
has the huge advantage of actually producing working results on ARM and PPC64.
The old JIT for non-x86 has bit-rotted a lot, to the point of crashing even for
simple examples.
> 
> 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. The JITInfo parts can stay, they may be useful if someone
wants to implement lazy compilation on top of MCJIT. It would become dead code
though.
> 
> The MCJIT for PPC only supports PPC64 currently. However, PPC32 old JIT
never worked for non-darwin platforms and seems to be broken even there at the
moment.
> 
> Any objections? x86 will stay around for a while, it's reasonably well
maintained and has many users.
> 
> - Ben
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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?

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.

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

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