similar to: [LLVMdev] Help turn the vectorizer bot green

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

Hello, I was interested in how much Type-Based Alias Analysis helps to optimize code. For that purpose, I've compared three sets of benchmarks: compiled without TBAA, compiled with a default TBAA metadata format, and compiled with new TBAA metadata format. As a set of benchmarks, I've used the LLVM test suite (http://llvm.org/docs/TestingGuide.html#test-suite-overview) which has a lot of

On Jul 5, 2012, at 1:33 AM, Duncan Sands wrote: > Hi Bill, > >> Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? > > I don't see any relevant LLVM changes, so I guess clang C++ compilation slowed > down due to some clang changes. I'm not going to investigate this. > Crumbs. John, Do you know of anything that went into

Target: FreeBSD 6.2-STABLE on i386 autoconf says: configure:2122: checking build system type configure:2140: result: i386-unknown-freebsd6.2 [...] configure:2721: gcc -v >&5 Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 [...] objdir != srcdir, for both llvm and gcc. Release build. llvm-gcc 4.2 from source.

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, LLVM 2.1-pre1 test results: Linux (SUSE) on x86 (P4) Release mode, but with assertions enabled LLVM srcdir == objdir # of expected passes 2250 # of expected failures 5 I ran the llvm-test suite on my desktop while I was also working on that PC, so don't put too much trust in the timing info. Especially during the "spiff" test the machine was swapping

Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? -bw On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > Did something change with exception handling recently? A bunch of lit bots are > showing slower compile times for many tests. > > Ciao, Duncan. > > On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu

Hi Bill, > Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? I don't see any relevant LLVM changes, so I guess clang C++ compilation slowed down due to some clang changes. I'm not going to investigate this. Ciao, Duncan. > > -bw > > On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > >> Did

On Fri, Sep 14, 2007 at 11:42:18PM -0700, Tanya Lattner wrote: > The 2.1 pre-release (version 1) is available for testing: > http://llvm.org/prereleases/2.1/version1/ > > [...] > > 2) Download llvm-2.1, llvm-test-2.1, and the llvm-gcc4.0 source. > Compile everything. Run "make check" and the full llvm-test suite > (make TEST=nightly report). > > Send

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

Target: FreeBSD 7.0-RC1 on amd64. autoconf says: configure:2122: checking build system type configure:2140: result: x86_64-unknown-freebsd7.0 [...] configure:2721: gcc -v >&5 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] [...] objdir != srcdir, for both llvm and gcc. Release

Hello; I was able to build and install llvm(3.0) under Ubuntu 11.10 (using the ./configure script found under llvm source, and then make and make install). While configuring, I gave --prefix as a directory where I would like llvm to be installed. I did not give --with-llvmgccdir and the --enable-optimized argument to configure. Because 3.0 doesn't come with llvmgcc source/binaries and I

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:

On Sun, Jan 20, 2013 at 1:26 PM, Redmond, Paul <paul.redmond at intel.com> wrote: > 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:

Did something change with exception handling recently? A bunch of lit bots are showing slower compile times for many tests. Ciao, Duncan. On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: > > lab-mini-03__O0-g__clang_DEV__x86_64 test results > <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> > > Run Order Start Time Duration >

On Oct 20, 2009, at 6:02 AM, Duncan Sands wrote: > Hi Tanya, > >> 1) Compile llvm from source and untar the llvm-test in the projects >> directory (name it llvm-test or test-suite). Choose to use a pre- >> compiled llvm-gcc or re-compile it yourself. > > I compiled llvm and llvm-gcc with separate objects directories. > Platform is x86_64-linux-gnu. > Ok.

While porting my backends to llvm-3.2, I found a few places where the optimizers could have performed better. I believe the mainstream targets can also benefits from my tweaks. But before upstreaming my changes, I would like to quantify their merits on other applications --- not just my domain specific codes. In a word, it seemed the right time for me to start using LNT :) I followed the

G'Day Tanya, Is it too late to bring in the following patches to fix some major brokenness in the AuroraUX tool chain for 2.6? http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84468&r2=84469&view=diff&pathrev=84469 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84265&r2=84266&view=diff&pathrev=84266

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, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting