Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] mc jit"
2012 Jun 19
2
[LLVMdev] mc jit
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 ::
2012 Jun 19
0
[LLVMdev] mc jit
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
2012 Jun 19
0
[LLVMdev] mc jit
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 ::
2012 Jun 19
1
[LLVMdev] mc jit
On Mon, Jun 18, 2012 at 08:49:20PM -0700, reed kotler wrote:
> I think you mean to say:
>
> make check-all LIT_ARGS=--param=jit_impl=use-mcjit
Hrm, I was told that I can use LIT_ARGS=--param=jit_impl=mcjit.
Does yours make those failures go away? :)
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
2014 Jul 22
2
[LLVMdev] [LLVMDev][3.5]: assertion failed in RuntimeDyldELF.cpp
Hi LLVMDev list
I am building LLVM from the SVN trunk at 213638 on a W7/X86_64/Cygwin
system and running make check leads to a series of failed assertions like
********************
FAIL: LLVM :: ExecutionEngine/MCJIT/test-setcond-fp.ll (6185 of 11245)
******************** TEST 'LLVM ::
ExecutionEngine/MCJIT/test-setcond-fp.ll' FAILED ********************
Script:
--
2014 Jul 25
2
[LLVMdev] [LLVMDev][3.5]: assertion failed in RuntimeDyldELF.cpp
Hi Lang
Le 24/07/2014 18:17, Lang Hames a écrit :
> Hi Francis,
>
> It is possible to XFAIL a regression test (grep for XFAIL in the
> llvm/test directory for examples), however that's discouraged. The
> fact that this test is failing indicates that part of the JIT
> infrastructure is broken on W7/X86_64/Cygwin.
>
> How long have you been building LLVM in this
2012 Jun 19
1
[LLVMdev] mc jit
> test/ExecutionEngine/MCJIT is currently a duplicate of test/ExecutionEngine, which runs the tests with MCJIT. So it already runs every time you "make check" (on build-bots too!). The duplication is unfortunate, but hopefully temporary - once the LIT SUBTEST patch gets in (it's been in review for ages now, ahem ;-) ) it should be gone and each test in test/ExecutionEngine will
2012 Jun 19
0
[LLVMdev] mc jit
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of reed kotler
> Sent: Tuesday, June 19, 2012 02:57
> To: ll >> "llvmdev at cs.uiuc.edu"
> Subject: [LLVMdev] mc jit
>
> I don't see any tests in either test or test-suite for -use-mcjit.
>
> Are we not testing this yet?
>
2013 Jan 08
2
[LLVMdev] [cfe-dev] ARM failures
The obvious difference is that you're using --enable-optimized and implicitly --disable-assertions. If you run the tests with
make check-all VERBOSE=1 'LIT_ARGS=-v ' > logfile
and grep for FAILED in logfile, does what's listed there give any more details? (Quite possible in a Release-Asserts build
it might not.)
Cheers,
Dave
-----Original Message-----
From: cfe-dev-bounces
2013 Jan 08
0
[LLVMdev] [cfe-dev] ARM failures
On Tue, Jan 8, 2013 at 8:31 PM, David Tweed <David.Tweed at arm.com> wrote:
> The obvious difference is that you're using --enable-optimized and implicitly --disable-assertions. If you run the tests with
>
> make check-all VERBOSE=1 'LIT_ARGS=-v ' > logfile
>
> and grep for FAILED in logfile, does what's listed there give any more details? (Quite possible in
2013 Jan 08
1
[LLVMdev] [cfe-dev] ARM failures
You can compare your configure/build arguments + environment with the build
bot:
http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4313/steps/configure/logs/stdio
I'll check how I built my LLVM on Chromebook tomorrow, but it didn't look
too different to yours.
--renato
On 8 January 2013 19:08, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Tue, Jan 8,
2013 Jan 08
0
[LLVMdev] ARM failures
On Tue, Jan 8, 2013 at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote:
> The following failures are consistent on buildbot (and my local box).
[...]
> LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
> LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.ll
It is interesting that I don't see this on my ARM box. Instead I see these:
Failing
2009 Feb 23
1
[LLVMdev] 2.5 Pre-release2 available for testing
On Mon, Feb 23, 2009 at 12:12 AM, Aaron Gray <
aaronngray.lists at googlemail.com> wrote:
> On Sun, Feb 22, 2009 at 11:15 PM, Anton Korobeynikov <
> anton at korobeynikov.info> wrote:
>
>>
>> Actually its [configure-stage3-intl] where its hanging.
>>
>> This can easily be due to inline FP math in the stdlib headers. For
>> example - I had to
2013 Jan 08
6
[LLVMdev] ARM failures
The following failures are consistent on buildbot (and my local box).
The Clang one I think it's assuming an Intel box, the other two look like
the FileCheck are not good enough.
http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4305
Clang :: CodeGen/compound-assign-overflow.c
LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll
LLVM ::
2012 Sep 19
0
[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
2012 Sep 19
3
[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
2012 Sep 21
1
[LLVMdev] How to use MCJIT by default for a target
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:
2011 Aug 31
1
[LLVMdev] Trouble using the MCJIT: "Target does not support MC emission" error
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
2011 Jun 24
1
[LLVMdev] MC-JIT (any progress?)
On 07/19/2010 05:14, Olivier Meurant wrote:
> Together with Jan Sjodin (in copy of this email), we begin an
> implementation of the JIT with MC. The idea, suggested by Jan, is to
> develop a MCJIT in parallel of the current JIT and to keep the two
> implementations until (at least) the new MC one is mature enough.
> Currently code is kept on gitorious
>
2011 Aug 26
2
[LLVMdev] Trouble using the MCJIT: "Target does not support MC emission" error
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