similar to: [LLVMdev] [llvm-testresults] Grawp i386 nightly tester results

On Jul 24, 2011, at 3:02 AM, Duncan Sands wrote: > A big compile time regression. Any ideas? > > Ciao, Duncan. False alarm. For some reason that I have not yet been able to figure out, these tests run significantly more slowly when I run them during the daytime, which I did for that run. I checked a few of the worst regressions reported here and they all recovered in subsequent

Yes, they are real. I re-ran the two tests with the biggest execution time regressions, and the results were completely reproducible. On Oct 12, 2011, at 1:24 AM, Duncan Sands wrote: > Hi Bob, are these performance regressions real? They look pretty serious. > > Ciao, Duncan. > > On 10/12/11 09:40, llvm-testresults at cs.uiuc.edu wrote: >> >>

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

Hi Bob, are these performance regressions real? They look pretty serious. Ciao, Duncan. On 10/12/11 09:40, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/332/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time >

On Feb 16, 2008, at 2:35 PM, Tanya Lattner wrote: > On Feb 16, 2008, at 12:55 PM, Dale Johannesen wrote: >>> Using built-in specs. >>> Target: i686-apple-darwin9 >>> Configured with: /tmp/llvmgcc42.r46865.roots/llvmgcc42.r46865~obj/ >>> src/configure --disable-checking --enable-werror --prefix=/ >>> Developer/ >>> usr/llvm-gcc-4.2

But I am using llvm-gcc-4.2. Any idea why it's failing? Evan On Feb 16, 2008, at 11:24 AM, Dale Johannesen wrote: > On Feb 16, 2008, at 7:06 AM, Apache wrote: >> New Test Failures: >> test/C++Frontend/2008-02-13-sret.cpp [DEJAGNU] > > This test doesn't work with gcc-4.0, which caused it to fail on a > number of testers overnight. I can fix that in 4.0, but as I

On Feb 16, 2008, at 7:06 AM, Apache wrote: > New Test Failures: > test/C++Frontend/2008-02-13-sret.cpp [DEJAGNU] This test doesn't work with gcc-4.0, which caused it to fail on a number of testers overnight. I can fix that in 4.0, but as I understand it we're going to drop support for it next release, so how about now?

On Feb 16, 2008, at 12:55 PM, Dale Johannesen wrote: >> >> Using built-in specs. >> Target: i686-apple-darwin9 >> Configured with: /tmp/llvmgcc42.r46865.roots/llvmgcc42.r46865~obj/ >> src/configure --disable-checking --enable-werror --prefix=/Developer/ >> usr/llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man -- >>

llvm itself is built with gcc-4.0, but the run line is: // RUN: %llvmgxx -S -O0 -emit-llvm %s -o - | grep retval | grep S242 | grep {i32 1} | count 2 According the log: FAIL: /Volumes/Muggles/LLVM/nightlytest-pic/build/llvm/test/C+ +Frontend/2008-02-13-sret.cpp Failed with exit(1) at line 1 while running: /usr/local/bin/llvm-gcc -emit-llvm -S -O0 -emit-llvm /

> > Using built-in specs. > Target: i686-apple-darwin9 > Configured with: /tmp/llvmgcc42.r46865.roots/llvmgcc42.r46865~obj/ > src/configure --disable-checking --enable-werror --prefix=/Developer/ > usr/llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man -- > enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program- >

On Feb 16, 2008, at 11:32 AM, Evan Cheng wrote: > But I am using llvm-gcc-4.2. Any idea why it's failing? > > Evan All the failing testers are using gcc-4.0 according to the web pages they point at. > On Feb 16, 2008, at 11:24 AM, Dale Johannesen wrote: > >> On Feb 16, 2008, at 7:06 AM, Apache wrote: >>> New Test Failures: >>>

Friday I enabled the inlinehint function attribute in the inliner. It mostly affects the performance of -Os compiled code. I have made some measurements on the SPEC test suite to show what it means. I made three runs of then nightly tests. The baseline represents -Os with no inlinehint: make TEST=nightly OPTFLAGS=-Os EXTRA_LOPT_OPTIONS=-inlinehint-threshold=0

Perhaps you noticed that LLVM gained a new optimizing register allocator yesterday (r130568). Linear scan is going away, and RAGreedy is the new default for optimizing builds. Hopefully, you noticed because your binaries were suddenly 2% smaller and 10% faster*. Some noticed because LLVM started crashing or miscompiling their code. Greedy replaces a fairly big chunk of the code generator, so

Are these 225 compile time regressions real? It sure looks bad! Ciao, Duncan. On 01/12/11 09:39, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/380/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time > Current 380

Hi Devang, Unfortunately, there's no way to see the build log unless you're on the machine from which the report was generated. If you can log in to Grawp's machine then it should be in the "WEBDIR". It is most likely mis-compiling because the needed llvm-gcc patch has not been applied after the SETCC patch to LLVM was committed last weekend. Reid. On Fri, 2006-12-29 at

Jim Laskey wrote: > llvm[4]: Compiling stacker_rt.ll to stacker_rt.bc for Release build > (bytecode) > /Volumes/Muggles/LLVM/nightlytest/build/llvm/Release/bin/gccas: / > Volumes/Muggles/LLVM/nightlytest/build/llvm/projects/Stacker/lib/ > runtime/Release/stacker_rt.ll:21,0: parse error, expecting `LOAD' or > `STORE' >

On Sat, 30 Dec 2006, Reid Spencer wrote: > You all just need remove "stacker_rt.ll". the stacker_rt.ll is a > generated file, not source. The Makefile should have a dependency on > llvm-gcc for it, but doesn't. Just remove stacker_rt.ll and the problem > will go away. This presumably doesn't impact the testers, as they start from a clean build every night. The

On Sat, 2006-12-30 at 11:53 -0800, Chris Lattner wrote: > On Sat, 30 Dec 2006, Reid Spencer wrote: > > You all just need remove "stacker_rt.ll". the stacker_rt.ll is a > > generated file, not source. The Makefile should have a dependency on > > llvm-gcc for it, but doesn't. Just remove stacker_rt.ll and the problem > > will go away. > > This

On Sat, 30 Dec 2006, Reid Spencer wrote: >>> You all just need remove "stacker_rt.ll". the stacker_rt.ll is a >> rebuilt so they output proper .ll files. Reid, can you change the >> makefile rule to use "llvm-gcc -S -emit-llvm -o - | llvm-upgrade > $@" or >> the equivalent? > > Which makefile rule? The rule in the stacker makefile that

So when will the public mirror be updated? That version of llvm-gcc still doesn't have the patch. Reid Spencer wrote: > On Mon, 2007-01-01 at 00:44 -0800, Evan Cheng wrote: > >> Ok, so I guess the issue is llvm-gcc has to be updated. There are >> some issues with the Apple svn repository so I checked out a copy >> from the public mirror. Looks the latest