[LLVMdev] Removing old JIT CodeEmitters for ARM and PPC

Benjamin Kramer benny.kra at gmail.com
Sat Nov 24 09:05:24 PST 2012


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
> 





More information about the llvm-dev mailing list