similar to: [LLVMdev] MultiSource/Applications/lemon slow in JIT

On May 21, 2008, at 6:09 AM, Matthijs Kooijman wrote: > Hi, > > I've been toying around with the testsuite for a bit, and after > recompiling > llvm-gcc a bunch of times and fixing a nasty bashism bug, I actually > got it to > run and pass most tests. > > When running, I noticed a very long runtime on the lemon test. At > first I > suspected an infinite

Evan Cheng wrote: > On May 21, 2008, at 6:09 AM, Matthijs Kooijman wrote: > > >> Hi, >> >> I've been toying around with the testsuite for a bit, and after >> recompiling >> llvm-gcc a bunch of times and fixing a nasty bashism bug, I actually >> got it to >> run and pass most tests. >> >> When running, I noticed a very long

On Wed, May 7, 2014 at 8:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Anton Korobeynikov" <anton at korobeynikov.info> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Alexey Samsonov" <samsonov at google.com>, "LLVM Developers Mailing > List" <llvmdev at

On May 21, 2008, at 11:45 AM, Török Edwin wrote: > The forking was introduced because the runtime was too small; I think this direction is wrong. I'd rather have some infrastructure that can get nanoseconds or tick counters and print them... This then allows for a microbenchmark suite, which I think fits in nicely with the llvm philosophy.

After the removal of llvm/test/Programs and insertion of llvm-test cvs module, the nightly tester showed the following: x86 Linux debug: * hard to say. I think it failed because the check in occurred just as it was starting up. Could someone verify for me? No results were produced. x86 Linux optimized: * everything ran okay * loc graph now shows 550k lines (up 350k!) - not sure

Chris Lattner wrote: > One way to do this is to add a "cut down" version of the app to the > test suite. I disabled optional features in clamav-config.h > >> 2. GPL license. Chris? > > Any open source license that allows unrestricted redistribution is > fine in llvm-test Ok, I have created a script that automatically checks out ClamAV 0.92-stable source code

Hi, I get the following failures when I run the test-suite on linux (Ubuntu 12.04) using LNT (lnt runtest nt ...): (all are execution failures) MultiSource/Applications/Burg MultiSource/Applications/ClamAV MultiSource/Applications/lemon MultiSource/Applications/obsequi MultiSource/Benchmarks/MiBench/automotive-bitcount

Does anyone know if this is a known xfail? I'm getting a failure for Mips on this but at the same time, ecmascript.y gets errors when running it through lemon for both gccx86 and llvm mips so I don't know if the output is supposed to really compare or not. (This test runs lemon on multiple input files and computes a hash of the result and diffs the hash). All inputs that are not

Hi, I figured out how to resolve the failures. I noticed that Mountain Lion includes Bison 2.3 while Ubuntu 12.04 includes Bison 2.5. I installed Bison 2.3 from source in Ubuntu and the failures went away. I'm a little concerned that the bison version fixed all the failures I was seeing. To my knowledge the only failing test that depended on bison was Burg. It almost looks like one failure

On Mon, 17 Dec 2007, Evan Cheng wrote: > We always welcome more tests. But it looks like there are two issues > here. > > 1. The autoconf requirement. Is it possible to get one configuration > working without the need for autoconf? One way to do this is to add a "cut down" version of the app to the test suite. > 2. GPL license. Chris? Any open source license that

There is almost certainly a bug in lnt or the makefiles. I changed the body of Burg main to the following: + printf("Hello World\n"); + return 0; I re-ran the test-suite again and got the following errors: --- Tested: 986 tests -- FAIL: MultiSource/Applications/Burg/burg.execution_time (494 of 986) FAIL: MultiSource/Applications/ClamAV/clamscan.execution_time (495 of 986) FAIL:

Hi Edwin, I ran into two problems. 1. Using your config file and Makefile, I ran into issue compiling with gcc: gcc -I/Users/echeng/LLVM/llvm/projects/llvm-test/MultiSource/ Applications/ClamAV -I/Users/echeng/LLVM/llvm/projects/llvm-test/ MultiSource/Applications/ClamAV -I/\Users/echeng/LLVM/llvm/include -I/ Users/echeng/LLVM/llvm/projects/llvm-test/include -I../../..//include

Hello all, I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or 33, 34) *pNoGen with SCEV canonicalization (run 32): -O3 -Xclang -load

Hi Folks, Looks like our LNT ARM buildbot with the vectorizer is running and producing good results. There are only 11 failures: FAIL: MultiSource/Applications/Burg/burg.execution_time (1 of 1104) FAIL: MultiSource/Applications/ClamAV/clamscan.execution_time (2 of 1104) FAIL: MultiSource/Applications/lemon/lemon.execution_time (3 of 1104) FAIL:

A big compile time regression. Any ideas? Ciao, Duncan. On 22/07/11 19:13, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/253/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time > Current 253 0 2011-07-22 16:22:04

I have built and configured the test suits as told at http://llvm.org/docs/TestingGuide.html#testsuite. The llvm is built with configuration: SRC_DIR/configure --prefix=INS_DIR --enable-debug-runtime --disable-optimized --enable-debug-symbols --enable-assertions This configuration is used again in the re-configure process. However, after the re-configure process, the following "make"

All SingleSource and MultiSource tests failed in last run of FreeBSD nighttester (and in previous). Mostly with error: ---8X--------------------- gcc -O3 Output/2002-05-02-CastTest3.llc-ls.s -lm -o Output/2002-05-02-CastTest3.llc-ls /var/tmp//ccwC1BGs.o(.text+0x14): In function `main': : undefined reference to `__llvm_getGlobalCtors' /var/tmp//ccwC1BGs.o(.text+0x2b): In function

Hi all, Is anyone else seeing tests in the Multisource/Applications directory failing with something looking like this: /Users/wendling/llvm/llvm.obj/Debug/bin/gccld -L/Users/wendling/llvm/ llvm-gcc4.install/lib/gcc/powerpc-apple-darwin8.8.0/3.4-llvm -L/ Users/wendling/llvm/llvm-gcc4.install/lib Output/siod.linked.bc -lc -lpthread -lltdl -lm -o Output/siod.llvm gccld: warning: Cannot

Configure gives me these errors on FreeBSD. I'm proceding with the build anyway to see what happens. Don't worry :) It'll only take about 2.5 hours instead of 30+ now. install: ../test/Programs/Makefile does not exist config.status: executing test/Programs/Makefile.programs commands install: ../test/Programs/Makefile.programs does not exist config.status: executing

On 09/08/2013 08:03 PM, Star Tan wrote: > Hello all, > > > I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Interesting. > Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or