similar to: CTMark - regular LLVM and CLANG compile-time tracking

> On Nov 17, 2016, at 2:55 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi Gerolf, > > This is really cool! > I’m very excited about this initiative and I hope we’ll be able to get to a stage where compile time regression are handled like other regression: if they are not expected / justified by the commit author promptly, the commit should be reverted in the

> On Apr 11, 2017, at 10:25 PM, Madhur Amilkanthwar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am interested in knowing more. > 1. What benchmarks does LLVM community use for compile-time study? I see CTMark, but is that the only one being analyzed? CTMark is not cast in stone. Its purpose is for the community to have a trackable proxy for the overall llvm test

On Sun, Dec 18, 2016 at 11:10 AM, Philip Reames <listmail at philipreames.com> wrote: > On 12/17/2016 01:35 PM, Davide Italiano via llvm-dev wrote: >> [...] > > I'd really like to see a profile which broke down the time spent in Value > Propagation and LVI. As the person who has touched both most recently, I am > probably the responsible party. At the same time,

Can you share you compile-time and memory footprint measurements at least for CTMark? For a new pass/feature it would be great to share this with the community before you commit. Or did I miss them? Thanks Gerolf > On Jun 27, 2017, at 3:26 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > EarlyCSE w/ MemorySSA has been enabled by default as of r306477 >

Hi, It's been a while since I sent the last compile time report [1], where it was shown that LLVM was getting slower over time. But now I'm happy to bring some good news: finally, LLVM is getting faster, not slower :) *** Current status *** Many areas of LLVM have been examined and improved since then: InstCombine, SCEV, APInt implementation, and that resulted in almost 10% improvement

And this one, with LLVM ~3.0: http://www.phoronix.com/scan.php?page=article&item=amd_bulldozer_compilers&num=1 -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Martin Whitaker Sent: Thursday, November 03, 2011 11:01 Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] The performance of LLVM vs GCC [and copy to

AMD is dropping support for the R300-R500 cards in their official drivers: http://www.phoronix.com/scan.php?page=article&item=amd_r500_legacy&num=1 As the current open source drivers do not support 3D, I'd like to know which Compiz effects use 3D and which use 2D. Thanks. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il

FYI http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1

> 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

> To (hopefully) make it easier to answer this question, I've posted my (work-in-progress) patch which adds a known-bits cache to InstCombine. > I rebased it yesterday, so it should be fairly easy to apply: https://reviews.llvm.org/D31239 - Seeing what this does to the performance of the > benchmarks mentioned in this thread (among others) would certainly be interesting. Thanks! I

Hi all, This talk includes the performance comparison between LLVM and GCC (page 30/31): LLVM wins a lot for both compilation and execution time. http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf That talk and data were in 2008, I was wondering if there is any updated performance evaluation between the latest LLVM and GCC? Thanks. -- Jianzhou

Hi everyone. I read on a 2011 article - http://www.phoronix.com/scan.php?page=article&item=nouveau_comp_2011&num=19 - that my particular card, GeForce 8400 GS, overheats with nouveau. (So, I never tried using if for long, before, as soon as possible, installing the proprietary drivers...) But, because it's a 2-year-old article, I was wondering if that problem could have been, in the

[and copy to list] Jianzhou Zhao wrote: > Hi all, > > This talk includes the performance comparison between LLVM and GCC > (page 30/31): LLVM wins a lot for both compilation and execution time. > http://llvm.org/pubs/2008-10-04-ACAT-LLVM-Intro.pdf > That talk and data were in 2008, I was wondering if there is any > updated performance evaluation between the latest LLVM and

http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 as of version 2.8, LLVM is generating slower code than the newer GCCs but generates the code more quickly.

Hi Edwin, >> http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 >> as of version 2.8, LLVM is generating slower code than the newer GCCs >> but generates the code more quickly. >> > > I would be more concerned about the 'unable to compile', or 'compiled > code not working correctly' issues. It would help if they

On 11/03/11 10:11, Rotem, Nadav wrote: > And this one, with LLVM ~3.0: > > http://www.phoronix.com/scan.php?page=article&item=amd_bulldozer_compilers&num=1 What, no dragonegg?! :) Ciao, Duncan.

http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1 Regards, Stefano

On 27 April 2010 08:18, Stefano Delli Ponti <stefano.delliponti at gmail.com> wrote: > FYI > http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1 For Apache and Dhrystone, the performance boost is good (but only the former is really important), but for the rest, especially those with image/sound processing, and HMMR, it's still far behind. Is this only

On Wed, Feb 18, 2015 at 1:39 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Feb 18, 2015 at 12:04:47PM -0500, Jack Howarth wrote: >> My concern is that, without strict enforcement of the triaging >> serious P1-type bugs, the major llvm.org releases will devolve into a >> continual exchange of one set of major regressions for another set.

Hi Kristof, Thanks for the measurements. > On May 24, 2017, at 6:00 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 23 May 2017, at 21:48, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Great! >> I thought I had to look at our pipeline at O0 to make sure optimized regalloc was