[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
benny.kra at gmail.com
Sun Nov 25 02:16:42 PST 2012
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
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.
More information about the llvm-dev