Benjamin Kramer
2012-Nov-24 16:06 UTC
[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 llvm.cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20121124/721144ea/attachment.html>
Benjamin Kramer
2012-Nov-24 17:05 UTC
[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
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 llvm.cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Chris Lattner
2012-Nov-24 22:39 UTC
[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
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 llvm.cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Albert Graef
2012-Nov-24 23:34 UTC
[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
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: musikinformatik.uni-mainz.de/ag
Benjamin Kramer
2012-Nov-25 10:16 UTC
[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
Reasonably Related Threads
- [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
- [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
- [LLVMdev] Question about compiling LLVM through cross-compiler for ARM
- [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC
- [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC