Hi, I'm looking into making MCJIT the default for the ARM-Linux-EABI target for lli. (WHY? the old JIT doesn't really work on ARM, and in particular there are some regression tests of interesting things -- such as profiling -- that fail purely because the default old JIT doesn't work. So a consensus has been reached that the best way forward is to try to make the MCJIT the default for ARM-Linux-EABI and see if that's workable.) Looking at the lli source code, there's the option UseMCJIT that defaults to false. You can also use -use-mcjit, -use-mcjit=true, -use-mcjit=false. Things would be fine if we could make the option default architecture dependent. However, these defaults are all set-up BEFORE we commit to what architectural triple we're using (as the target triple can be specified via argument). If we try to mess with the option based on the triple after it's gone through parsing rather than the default, we can't distinguish between "false (from default)" and "false (set deliberately)". All this does assume, of course, that it's important to provide a way for the user to stop lli using the MCJIT; I think that's probably wise but maybe it's unnecessary. Anyway, this sounds like making a default choice based on a target-triple is something that probably ought to be done "using canonical idiom" so it's easily grokked rather than using an ad-hoc approach. Does anyone have any thoughts? Many thanks, David Tweed -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi David, 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. All I really know so far is that when using profiling metadata a pseudo-instruction is generated which the ARM JIT does not support. Regards, Alastair.
It seems to me that MCJIT would be a nice default on the platforms that support it. On the other hand, I don't like the idea of the default behavior being platform dependent. Perhaps the biggest obstacle to changing the default is that it would have complicated implications for the automated tests. The testing of JIT and MCJIT is already a bit of a mess, and changing the default to MCJIT for some platforms while leaving it as JIT for other platforms would make things considerably worse. I think at this point we'd need to consider cleaning up the JIT/MCJIT nightly tests as a pre-requisite to changing the default, regardless of other considerations. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Tweed Sent: Tuesday, September 18, 2012 8:22 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] How to use MCJIT by default for a target Hi, I'm looking into making MCJIT the default for the ARM-Linux-EABI target for lli. (WHY? the old JIT doesn't really work on ARM, and in particular there are some regression tests of interesting things -- such as profiling -- that fail purely because the default old JIT doesn't work. So a consensus has been reached that the best way forward is to try to make the MCJIT the default for ARM-Linux-EABI and see if that's workable.) Looking at the lli source code, there's the option UseMCJIT that defaults to false. You can also use -use-mcjit, -use-mcjit=true, -use-mcjit=false. Things would be fine if we could make the option default architecture dependent. However, these defaults are all set-up BEFORE we commit to what architectural triple we're using (as the target triple can be specified via argument). If we try to mess with the option based on the triple after it's gone through parsing rather than the default, we can't distinguish between "false (from default)" and "false (set deliberately)". All this does assume, of course, that it's important to provide a way for the user to stop lli using the MCJIT; I think that's probably wise but maybe it's unnecessary. Anyway, this sounds like making a default choice based on a target-triple is something that probably ought to be done "using canonical idiom" so it's easily grokked rather than using an ad-hoc approach. Does anyone have any thoughts? Many thanks, David Tweed -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150406. html 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! Cheers, David
陳韋任 (Wei-Ren Chen)
2012-Sep-19 08:39 UTC
[LLVMdev] How to use MCJIT by default for a target
On Wed, Sep 19, 2012 at 12:42:18AM +0000, Kaylor, Andrew wrote:> It seems to me that MCJIT would be a nice default on the platforms that support it. On the other hand, I don't like the idea of the default behavior being platform dependent. > > Perhaps the biggest obstacle to changing the default is that it would have complicated implications for the automated tests. The testing of JIT and MCJIT is already a bit of a mess, and changing the default to MCJIT for some platforms while leaving it as JIT for other platforms would make things considerably worse. I think at this point we'd need to consider cleaning up the JIT/MCJIT nightly tests as a pre-requisite to changing the default, regardless of other considerations.I agree that we should clean up JIT/MCJIT tests, then change to MCJIT until it pass those tests. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Hi David, On 19/09/12 04:10, David Tweed wrote:> 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: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150406. > htmlI managed to completely miss that message. Glad to know that a solution already exists, even if there are some complications in using it. Regards, Alastair.