similar to: [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

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. -Andy -----Original Message----- From: llvmdev-bounces at

Anything to remove the current duplication in test code between ExecutionEngine & ExecutionEngine/MCJIT is a step forward. While that mess is tidied up, we may as well factor in a solution to allow setting default JITs. IMO target support for MCJIT would improve faster if at some point the transition was made completely. It's going to happen eventually, and the sooner for those targets

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

> 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 I don't see this patch get

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

Hi Dmitri, You're right. The lli code should be cleaned up. As David said, there was a time when the call to invalidate the instruction cache was necessary. It isn't necessary anymore. -Andy -----Original Message----- From: Dmitri Rubinstein [mailto:dmitri.rubinstein at googlemail.com] Sent: Tuesday, June 04, 2013 7:20 AM To: David Tweed Cc: Kaylor, Andrew; LLVM Dev Subject: Re:

Hi all, I tried to modify Kaleidoscope Tutorial (toy.cpp from llvm/examples/Kaleidoscope/Chapter7, LLVM 3.3 release branch) in order to use MCJIT instead of JIT. I get segmentation fault when running toy.cpp with fibonacci example from the tutorial. My modified toy.cpp is in attachment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding

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

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

Am 04.06.2013 16:05, schrieb David Tweed: > | I am curious about JMM->invalidInstructionCache(), which I found in > | lli.cpp implementation. lli.cpp contains also call finalizeObject(), I > | just overlooked it. lli.cpp calls finalizeObject(), which calls > | applyPermissions, which in turn calls invalidateInstructionCache. So why > | lli.cpp does call

Following along from lli code, if you add a call to InitializeNativeTargetAsmPrinter() during setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in

ons 2011-08-31 klockan 10:51 +0200 skrev Ralf Karrenberg: > Hi Matt, hi Bruno, > > I am still struggling to use AVX via MCJIT on TOT... did you succeed yet? > > I seem to be unable to even get lli to run some code with the > "use-mcjit" flag. > I attached a test case that works fine for "lli y.bc" but exits with an > error for "lli -use-mcjit

On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >> >> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can you step through EngineBuilder::create() and see what's happening there? >> >> -Jim

Hi, In the process of looking at whether it's reasonable to make ARM use MCJIT by default, I was trying to check that x86-64 uses MCJIT by default (ie, lli doesn't need an explicit -use-mcjit to be passed). However, after instrumenting the constructors for both JIT and MCJIT, either lli doesn't default to using MCJIT on x86-64 or The construction/non-construction of a JIT/MCJIT object

On 5/14/2012 10:28 AM, Jim Grosbach wrote: > > On May 14, 2012, at 10:21 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> On 5/14/2012 9:51 AM, Jim Grosbach wrote: >>> >>>>> >>>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>>>

Or we can make Eli's lit SUBTEST patch in, so that we don't have to duplicate test cases for old JIT and MCJIT. Regards, chenwj [1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120521/143186.html -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage:

Compiled the 3.0.0 version of the source code , then tried lli --use-mcjit irfile.txt On both windows and linux, I got: LLVM ERROR: Unknow object format. If I omit the -use-mcjit option, the command works well. It seems to me that something about MCJIT is broken in the 3.0.0 version. Also tried to initialize an ExecutionEngine from code, got errors like "Target does not support MC

On May 14, 2012, at 11:12 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >>> >>> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can

On 5/14/2012 9:51 AM, Jim Grosbach wrote: > >>> >>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>> >> >> Do I need to enable anything at configure, my configure looks like this: >>> ../llvm/configure --enable-libffi --enable-targets=host-only