search for: executionengines

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 ::

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

I think you mean to say: make check-all LIT_ARGS=--param=jit_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 ::

Hi Daniel, > Sebastian, this looks like it is most likely some kind of fallout from > your changes. Thanks for letting me know about these failing testcases. In the logs of the buildbot: http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio I see that the bot is configuring llvm with:

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,

On Fri, Nov 4, 2011 at 3:11 PM, <spop at codeaurora.org> wrote: > Hi Daniel, > >> Sebastian, this looks like it is most likely some kind of fallout from >> your changes. > > Thanks for letting me know about these failing testcases. > > In the logs of the buildbot: >

Hi, all It seems that rev. 131463 [1] makes LLVM failed to recognize ARM correctly. My best guess is the 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

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

Catching up on post-holiday 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

After re-cmaking and rebuilding everything from scratch, 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:

Hi, I got multiple failures on PowerPC64, crashes are the same: [ 1346s] 0 lli 0x00000000107bca00 [ 1346s] 1 lli 0x00000000107bcd14 [ 1346s] 2 lli 0x00000000107bcfb8 [ 1346s] 3 linux-vdso64.so.1 0x00000fff850f0418 __kernel_sigtramp_rt64 + 0 [ 1346s] 4 lli 0x00000000100bdc98 [ 1346s] 5 lli 0x00000000102f40d0 [ 1346s] 6

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 ::

Hi all, I am seeing a number of JIT unit test failures on AArch64. Some googling returns past discussions (circa 2014) but as far as I can tell, everything should be working. I listed the failures below. These are from a Release build. A Debug build does not exhibit the failures. I built with gcc 6.1.0 on SuSE 12. Switching to gcc 8.2.0 also makes the problem go away, both in Debug and

Hi Lang, I am on Ubuntu 14.04. I am building ToT: llvm, clang, polly, lld, compiler-rt, libcxx, libcxxabi. The build compiler is: clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04 The failures show up during "make check-all". My cmake command was: cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/w/c/org -DLLVM_TARGETS_TO_BUILD:STRING=all

I actually tend to agree with spop, it's cleaner to compute things at runtime than at compile time. One particular reason is wanting to pick the best target CPU for the current arch (which may not be what was compiled for). The current JIT target selection logic is really gross, I do believe that it tried to do this, but it probably needs some spring cleaning. Sebastian, can you try and take

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

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 module...

> 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.