search for: executionengine

On 06/18/2012 07:21 PM, 陳韋任 (Wei-Ren Chen) wrote: > make check-all LIT_ARGS=--param=jit_impl=mcjit Thanks. When I run this on x86 ubuntu, there are 47 failures. Failing Tests (47): LLVM :: ExecutionEngine/MCJIT/2002-12-16-ArgTest.ll LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/MCJIT/2003-01-04-LoopTest.ll LLVM :: ExecutionEngine/MCJIT/2003-01-04-PhiTest.ll LLVM :: ExecutionEngine/MCJIT/2003-01-09-SARTest.ll LLVM :: ExecutionEngine/MCJIT/200...

On Mon, Jun 18, 2012 at 04:56:53PM -0700, reed kotler wrote: > I don't see any tests in either test or test-suite for -use-mcjit. For ARM, we need to manually switch to use mcjit, say $ make check-all LIT_ARGS=--param=jit_impl=mcjit Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799

...it_impl=use-mcjit On 06/18/2012 08:24 PM, reed kotler wrote: > On 06/18/2012 07:21 PM, 陳韋任 (Wei-Ren Chen) wrote: >> make check-all LIT_ARGS=--param=jit_impl=mcjit > Thanks. > > When I run this on x86 ubuntu, there are 47 failures. > > Failing Tests (47): > LLVM :: ExecutionEngine/MCJIT/2002-12-16-ArgTest.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-04-LoopTest.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-04-PhiTest.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-09-SARTest.ll > LLV...

...d bot will generate code for "i686-pc-mingw32". I think that these fails are due to the fact that the testcases are not working when the target is specified to be different than host: in the following list of failing testcases I see the JIT cases failing: Failing Tests (26): LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll...

I don't see any tests in either test or test-suite for -use-mcjit. Are we not testing this yet? There are lots of other llc options. What is our plan for testing these?

I found the following problem when I try to debug "target does not support mc emission" in linux (the same code executes OK in windows): Below is a snippet extracted from this method, if (UseMCJIT && ExecutionEngine::MCJITCtor) { ExecutionEngine *EE = ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, OptLevel, AllocateGVsWithCode, TM); if (EE) return EE; } else if (ExecutionEngine::JITCtor) { ExecutionEngine *EE = ExecutionEngine...

..."i686-pc-mingw32".  I > think that these fails are due to the fact that the testcases are not > working when the target is specified to be different than host: in the > following list of failing testcases I see the JIT cases failing: > > Failing Tests (26): >    LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll >    LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll >    LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll >    LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll >    LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll >    LLVM :: ExecutionEngine/2003-05-07...

...he variable LLVM_HOSTTRIPLE got something like "armv7l-unknown-linux-gnueabi" when LLVM compiled natively on ARM. Then the Arch (armv7l) is not recognized by LLVM. As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log), there are a lot failure while running test cases under ExecutionEngine/. Those failure are disappeared when I cross compile LLVM. Maybe LLVM_HOSTTRIPLE got the *right* value, i.e., arm-unknown-linux-gnueabi. Currently, I handcode "Arch = "arm"" to make native compiled LLVM pass most test cases [2]. Is there a better way to make sys::getHostTripl...

On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > s/ExecutionEngine/EE/ (or something like buzzword!) I don't really know the best bikeshed color here. Jim? My lame idea would be: ExecutionEngine -> JIT ExecutionEngine -> JIT/Legacy ExecutionEngine/MCJIT -> JIT/MC ExecutionEngine/OProfileJIT -> JIT/OProfile ExecutionEngine/IntelJITEvenst -> JI...

...emails. I may have comments on the more general stuff later, but wanted to respond to this bit more quickly. On Nov 22, 2012, at 3:05 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> s/ExecutionEngine/EE/ (or something like buzzword!) > > I don't really know the best bikeshed color here. Jim? > > My lame idea would be: > > ExecutionEngine -> JIT > ExecutionEngine -> JIT/Legacy > ExecutionEngine/MCJIT -> JIT/MC > ExecutionEngine/OProfileJIT -> JIT/OPr...

...cratch, I'm seeing failures in MCJIT. It this something known or expected? I build LLVM/clang with pre-packaged clang-3.7.0, with "-stdlib=libc++". Example failure: /w/bld/org/./bin/lli -remote-mcjit -mcjit-remote-process=/w/bld/org/./bin/lli-child-target /w/src/llvm.org/test/ExecutionEngine/MCJIT/remote/eh.ll -- Exit Code: 184 Command Output (stderr): -- warning: remote mcjit does not support lazy compilation terminating with uncaught exception of type int ERROR: Unexpected RPC call -- ******************** FAIL: LLVM :: ExecutionEngine/MCJIT/eh.ll (18164 of 33466) *****************...

...lli 0x00000000100bdc98 [ 1346s] 5 lli 0x00000000102f40d0 [ 1346s] 6 lli 0x00000000100180f4 [ 1346s] 7 libc.so.6 0x00000fff84c357ac [ 1346s] 8 libc.so.6 0x00000fff84c359d4 __libc_start_main + 4293391356 The following tests fail: LLVM :: ExecutionEngine/test-common-symbols.ll LLVM :: ExecutionEngine/test-constantexpr.ll LLVM :: ExecutionEngine/test-fp-no-external-funcs.ll LLVM :: ExecutionEngine/test-fp.ll LLVM :: ExecutionEngine/test-global-init-nonzero.ll LLVM :: ExecutionEngine/test-global.ll LLVM :: ExecutionEngine/test-interp-vec-arithm_float...

Here's the failing tests for rc2 on SLES11.3 (glibc 2.11, libstdc++4.7). I've done some amount of triaging what some critical elements of the failures are. Unabridged log is attached. Failing Tests (94): LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncIntInt LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncVoidBool LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestSerialization LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async LLVM-Unit :: Support/SupportTests/ThreadPoo...

...into undefined behavior territory but my guess is that's unlikely. -David ******************** Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. Testing Time: 5.12s ******************** Failing Tests (11): LLVM-Unit :: ExecutionEngine/MCJIT/./MCJITTests/MCJITTest.lazy_function_creator_lambda LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.DefineMaterializingSymbol LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.FallbackDefinitionGeneratorTest LLVM-Unit :: ExecutionEngine/Orc/./...

...mething known or expected? I build > LLVM/clang with pre-packaged clang-3.7.0, with "-stdlib=libc++". > > > Example failure: > > /w/bld/org/./bin/lli -remote-mcjit > -mcjit-remote-process=/w/bld/org/./bin/lli-child-target > /w/src/llvm.org/test/ExecutionEngine/MCJIT/remote/eh.ll > <http://llvm.org/test/ExecutionEngine/MCJIT/remote/eh.ll> > -- > Exit Code: 184 > > Command Output (stderr): > -- > warning: remote mcjit does not support lazy compilation > terminating with uncaught exception of type in...

...uot;.  I >> think that these fails are due to the fact that the testcases are not >> working when the target is specified to be different than host: in the >> following list of failing testcases I see the JIT cases failing: >> >> Failing Tests (26): >>    LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll >>    LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll >>    LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll >>    LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll >>    LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll >>    LLVM :: Execut...

Hi, I have a debug build with shared libraries (to reduce compilation time), but since yesterday, it's failing with an ExecutionEngine error: FAILED: : && /usr/lib/ccache/bin/c++ -fPIC -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11 -g -Wl,-z,defs -shared -Wl,-soname,libLL...

Right now, on X86, creating multiple ExecutionEngines in the same process causes an assertion. If it's supposed to always be a singleton, should there be a way to get the process's ExecutionEngine instance? This would, among other things, allow "lli" to execute bitcode that itself uses the ExecutionEngine.

I'm trying to set up some automated testing, and I'd like to have multiple instances of ExecutionEngines, so that the state from the first test doesn't alter the second state. Right now I'm doing something along the lines of: Module *emptyModule = new Module("emptyModule"); ExecutionEngine executionEngine = ExecutionEngine::create(emptyModule); ExistingModuleProvider modul...

> Now to compare it in detail with the much smaller program I've got and > maybe I'll figure out what's wrong with my call to > ExecutionEngine::create. That call is perfectly valid, actually. It works for me when linked with: g++ -o b b.o `llvm-config --ldflags` `llvm-config --libs engine jit` Cheers, -Mahadevan.