similar to: [LLVMdev] Instruction Scheduling

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

If you are interesting to play around X32, you may refer to http://sourceware.org/glibc/wiki/x32 to bootstrap a local environment on Linux. Yours - Michael -----Original Message----- From: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] On Behalf Of Liao, Michael Sent: Monday, June 04, 2012 5:09 PM To: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu

Hi Folks, Anyone got chance to review the patch adding X32 psABI support? Yours - Michael -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Liao, Michael Sent: Tuesday, June 05, 2012 11:18 AM To: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu; llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Subject: Re:

On 01 Sep 2006, at 10:05, Kenneth Hoste wrote: > >> >>> Also, it is possible to tell make only to compile benchmark X? How >>> can I >>> enforce this? >> >> Go into the directory for that benchmark, then run 'make' or >> whatever. > I tried tom compile each of the SPEC CPU2000 benchmarks using the make command is each respective

On 31 Aug 2006, at 23:46, Chris Lattner wrote: > On Thu, 31 Aug 2006, Kenneth Hoste wrote: >> Bummer. I think I'll contact the NAG support for more info on >> this. Can you >> show me the content of your Makefile.nagfortran? > > It is identical to yours. > >> Also, it is possible to tell make only to compile benchmark X? How >> can I >>

Hello, Some problems were solved, new ones arised... Getting closer though... The fixes for the previous problems are at the bottom of this email, bug reports will be submitted when all problems are solved. +++ New/remaining problems +++ Currently, 9/26 benchmarks compile and run succesfully. One (fma3d) still has a f95 related problem (see below). The other 16 are divided into two groups:

Hi, I have looked at the LLVM code generation quality using small test cases and in general it is better than I thought and in some cases better than gcc. However, there are still some gap in SPEC performance. I have not looked at the root cause of those gaps. Anyone who cares about LLVM performance need to take this seriously. For fair comparison, I used -fno-strict-aliasing in gcc to turn off

Thanks David. Unfortunately many of us cannot use GPL v3 gcc so it's hard for us to investigate this. One question, can you tell if gcc is inlining significantly more than llvm? We have reports that this is one of the issue plaguing eon performance. There are also some relatively well known spec optimizations that we haven't implemented. e.g.

> On Sep 9, 2014, at 1:47 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Tue, Sep 9, 2014 at 12:53 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: > Hi Chandler, > > I had observed some improvements and regressions with the new lowering. > > Here are the numbers for an Ivy Bridge machine fixed at

Hi Chandler, Thanks for fixing the problem with the insertps mask. Generally the new shuffle lowering looks promising, however there are some cases where the codegen is now worse causing runtime performance regressions in some of our internal codebase. You have already mentioned how the new shuffle lowering is missing some features; for example, you explicitly said that we currently lack of

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 >

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

Hi, Over the past six months, a MemorySSA-backed DSE implementation has been added to LLVM and it now covers almost all cases the existing DSE implementation does, plus adding a major new capability: eliminating stores across basic blocks. Thanks everyone involved with reviews, testing & patches! I think now would be a good time to start working towards switching to use MemorySSA-backed DSE

On Fri, 1 Sep 2006, Kenneth Hoste wrote: > Some problems were solved, new ones arised... Getting closer though... > The fixes for the previous problems are at the bottom of this email, > bug reports will be submitted when all problems are solved. Kenneth, In general, I am more than happy to help people on this list. It is good for the community and I enjoy helping people be successful

Everything builds fine on sparc. The configure script needs to be fixed though (see previous email). Sparc testing results: make check: # of expected passes 1189 # of expected failures 34 Regressions Single Source: None New Failures Single Source (new tests): 2005-05-12-Int64ToFP: llc,jit Regressions MultiSource: Applications/d/make_dparser: llc, cbe, jit

Hi, LLVM’s SLP-vectorizer is a new pass that combines similar independent instructions in a straight-line code. It is currently not enabled by default, and people who want to experiment with it can use the clang command line flag “-fslp-vectorize”. I ran LLVM’s test suite with and without the SLP vectorizer on a Sandybridge mac (using SSE4, w/o AVX). Based on my performance measurements

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"

Chris Lattner wrote: > On Thu, 12 May 2005, John Criswell wrote: > >> Here is a more complete list of regressions for the platforms listed >> below. Some of the regressions from the previous list I emailed a few >> days ago have been fixed or were false positives. Thanks to all >> who've helped fix things. >> >> We would like to try to get as many