similar to: [LLVMdev] Tree Stability + Testing

This nightly tester is now using an llvm-g++ that produces the new ODR linkage types. This means that many more functions are being considered by the inter-procedural optimization passes (for example, "linkonce" functions defined in a header). The result seems to be pretty huge swings (both good and bad) in the C++ tests in the testsuite, see below. Note that this tester is often

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

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

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 >

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

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 Mar 9, 2009, at 8:53 AM, Duncan Sands wrote: > This nightly tester is now using an llvm-g++ that produces the new > ODR linkage > types. This means that many more functions are being considered by > the > inter-procedural optimization passes (for example, "linkonce" > functions defined > in a header). The result seems to be pretty huge swings (both good

All, It seems there's been some llvm bit rot on Linux recently. The tester on Zion is getting wedged so it appears to never finish. I experienced the same thing when running the llc compiled version of MultiSource/Benchmarks/MallocBench/espresso. It went into an infinite loop. I have just set up a new nightly tester (machine=70) which you can view at:

Jeff, Actually, that was my fault. I forgot to remove the non-existent directories from the configure.ac file. That's done and committed now, so the advice is still the same: update configure script :) Reid. On Sun, 2004-09-05 at 09:53, Jeff Cohen wrote: > Configure gives me these errors on FreeBSD. I'm proceding with the build anyway to see what happens. Don't worry :)

On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: > While I've not reviewed the patch in too much detail, it looks > promising. Can you run some end-to-end benchmarks to make sure that > cache pressure in the full program or other variables not accounted > for in a micro-benchmark don't dominate performance? Specifically the > nightly tester includes a number

On Mar 24, 2010, at 2:47 PM, Török Edwin wrote: > On 03/17/2010 10:12 PM, Tanya Lattner wrote: >> The 2.7 binaries are available for testing: >> http://llvm.org/pre-releases/2.7/pre-release1/ >> >> You will also find the source tarballs there as well. >> >> We rely on the community to help make our releases great, so please help >> test 2.7 if you

On 03/17/2010 10:12 PM, Tanya Lattner wrote: > The 2.7 binaries are available for testing: > http://llvm.org/pre-releases/2.7/pre-release1/ > > You will also find the source tarballs there as well. > > We rely on the community to help make our releases great, so please help > test 2.7 if you can. Please follow these instructions to test 2.7: > > /To test llvm-gcc:/

On Mon, Feb 08, 2010 at 10:31:23AM -0800, Chris Lattner wrote: > On Feb 7, 2010, at 1:03 PM, Gregory Petrosyan wrote: > > >On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: > >>While I've not reviewed the patch in too much detail, it looks > >>promising. Can you run some end-to-end benchmarks to make sure that > >>cache pressure in the

On Jul 16, 2009, at 5:51 PM, Chris Lattner wrote: > > On Jul 16, 2009, at 2:30 PM, Marcel Moolenaar wrote: > >> >> BTW: I don't run Linux at all, so no Linux/ia64 support. >> I can see how that could be a problem for people. >> >> Anyway: my case is a weak one and I would understand if the >> target get axed without considering my email/request...

On Sun, 2004-08-29 at 16:01, Jeff Cohen wrote: > Fair enough... The following tests under MultiSource fail: > > Benchmarks/Olden/power > Benchmarks/OptimizerEval > Benchmarks/Ptrdist/ks > Benchmarks/MallocBench/perl > Applications/sgefa > > However, they also fail in the exact same way without my change. > OptimizerEval appears to be non-deterministic; it produces

> The nightly tester is used for two purposes: making sure that nothing > breaks (the unit tests) and keeping tabs on how well performance is doing > (the spec and most multisource tests). It's not a reliable way to do > serious benchmarking, but can give good insights into where things can be > improved. hm, one day, the great benchmarking will be a reason to use LLVM, so, i

On Sat, 2004-09-11 at 12:49, Jeff Cohen wrote: > For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It > didn't make a difference. So here are the failures for llvm-test. All > diffs are against the "native" output. > > ===================== MultiSource/Applications/sgefa > > cbe failed differently from jit/llc. First cbe: > > 84c84

On Fri, 30 Apr 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > > This one is just noise, if you look today it's 1.0's straight across the > > board. Also note that the test runs for 0.003 seconds, which is the > > resolution of the time command on the system the program is being run on: > > this is not a good test for checking performance. :) >

Hi, Sorry for the delay in response. I measured the code size change and noticed small changes in both directions for individual programs. I found a 30k binary size growth for the entire testsuite + SPEC. I attached an updated performance report that includes both compile time and performance measurements. Thanks, Nadav On Jul 14, 2013, at 10:55 PM, Nadav Rotem <nrotem at apple.com>

On Jul 16, 2009, at 2:30 PM, Marcel Moolenaar wrote: > > BTW: I don't run Linux at all, so no Linux/ia64 support. > I can see how that could be a problem for people. > > Anyway: my case is a weak one and I would understand if the > target get axed without considering my email/request... Hi Marcel, There are two levels of problems with the IA64 backend. On the first