[LLVMdev] How to use MCJIT by default for a target

Kaylor, Andrew andrew.kaylor at intel.com
Wed Sep 19 10:55:30 PDT 2012

One possible way to solve the problem is to add an extra substitution argument to the lli invocation in the test files, then in the lit config files define that substitution to be "--use-mcjit" if the host OS architecture is ARM and empty otherwise.

It's not a particularly elegant solution, but I think it would work.


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Tweed
Sent: Wednesday, September 19, 2012 1:11 AM
To: 'Alastair Murray'
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] How to use MCJIT by default for a target

Hi Andrew,

On 18/09/12 11:21, David Tweed wrote:
> in particular there are some regression tests of interesting things
> -- such as profiling -- that fail purely because the default old JIT 
> doesn't work.

|I've actually got LLVM currently compiling within an ARM QEmu install 
|to look at an assert within the ARM JIT code.  Profiling tests that I 
|submitted a few weeks ago are failing on ARM build-bots (assert in 
|lli), perhaps this is what you are referring to.
|If I can verify that the tests pass when using MCJIT is there any 
|interest in fixing it?  Obviously if they still break with MCJIT there 
|is something which definitely needs fixed.

Yep, this is the issue. Running on an ARM pandaboard I can confirm that it's due to issues with the old JIT in general which are fixed in MCJIT, and nothing to do with the profiling code being tested, as discussed in this thread:


As you can see, I'm very interested in getting this fixed, but it's one of those situations where there's not really any nice mechanism in place for the obvious solution, which is to use MCJIT when needed without requiring the user (or for regression tests, tester) to do anything special.

Any ideas anyone has would be great!


LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu

More information about the llvm-dev mailing list