similar to: [LLVMdev] Using benchmarks from SPEC (gcc, bzip2...)

On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of > loads/stores added by the "linearscan" register allocator (just like can be > done with the "local" allocator)? I still haven't

Hi, Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the spiller's class? Thanks, -- Silvio Ricardo Cordeiro --------------

On 25 Aug 2010, at 02:04, Silvio Ricardo Cordeiro wrote: > On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with

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

On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the

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 >

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

Many of you are probably wondering about the status of the 2.3 release. Unfortunately, this release has been very difficult and the list of regressions very high. The list has finally dwindled down to the following regressions: Linux/x86: SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT] MultiSource/Applications/minisat/minisat [CBE] Darwin/x86:

Hi, One of the most time-consuming passes in LLVM middle-end is InstCombine (see e.g. [1]). It is a very powerful pass capable of doing all the crazy stuff, and new patterns are being constantly introduced there. The problem is that we often use it just as a clean-up pass: it's scheduled 6 times in the current pass pipeline, and each time it's invoked it checks all known patterns. It

On 03/17/2017 04:30 PM, Mehdi Amini via llvm-dev wrote: > >> On Mar 17, 2017, at 11:50 AM, Mikhail Zolotukhin via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> One of the most time-consuming passes in LLVM middle-end is >> InstCombine (see e.g. [1]). It is a very powerful pass capable

> On Mar 17, 2017, at 6:12 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls being the

Summary ======= I'm planning on adjusting SimplifyCFG so that it doesn't turn two-entry phi nodes into selects until later in the pass pipeline, to give passes which can understand phis but not selects more opportunity to optimize. The thing I'm trying to do which made me think of doing this is described below, but from the benchmarking I've done it looks like this is overall a

> On Mar 17, 2017, at 6:12 PM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls

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

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

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Many of you are probably wondering about the status of the 2.3 > release. Unfortunately, this release has been very difficult and the > list of regressions very high. The list has finally dwindled down to > the following regressions: > ... > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] For my

> > * This claim is only partially tested, but I'm running the allocator right > now with the base constraints plus an extension which adds coalescing costs > and it's just passed CINT2006 without error. Not bad given that the > coalescing extension only took a couple of hours to write > Following up on this footnote - The PBQPBuilderWithCoalescing builder is now in the

On CINT2006 ARM64/ref input/lto+pgo I practically measure no performance difference for the 7 benchmarks that compile. This includes bzip2 (although different source base than in CINT2000), mcf, hmmer, sjeng, h364ref, astar, xalancbmk On Sep 15, 2014, at 11:59 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Gerolf Hoflehner"

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

Where we are on the subject... Are we sure EH is done for x86? These two tests have never worked on Mac OS X / x86: SPEC/CINT2006/471.omnetpp Shootout-C++/except Evan On Feb 9, 2008, at 2:57 PM, Dale Johannesen wrote: > > On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >>> After comparing the generated assembler code with native gcc code I >>> think the generated