similar to: [LLVMdev] Switching the new block placement pass on by default for 3.1

On Apr 15, 2012, at 6:42 PM, Chandler Carruth wrote: > Hello folks, > > I think I've fixed everything left to be fixed in block placement, and I would really like for it to be on by default in 3.1: > 1) I've been testing this as thoroughly as I can across a large amount of real-world code, so it shouldn't be too flaky. > 2) The code has been checked in and reviewed

Doesn't llvm-gcc support GCC's builtin_expect? Or does it transform it into nothing? On Wed, Oct 22, 2008 at 6:28 PM, Paul Biggar <paul.biggar at gmail.com> wrote: > Hi, > > I'm interested in whether or not there is a way of providing > source-level annotations to help LLVM with optimizations, similar to > VisualC++'s __assume facility >

On Fri, Apr 22, 2016 at 10:39 AM, Philip Reames <listmail at philipreames.com> wrote: > > > On 04/22/2016 09:20 AM, Sanjay Patel via llvm-dev wrote: > > I've proposed removing the llvm.expect intrinsic: > http://reviews.llvm.org/D19300 > > The motivation for this change is in: > http://reviews.llvm.org/D19299 > > For reference: > 1. We created an

Hi Danny, On Thu, Oct 23, 2008 at 8:16 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > Doesn't llvm-gcc support GCC's builtin_expect? > Or does it transform it into nothing? This isnt the same as GCC's builtin-expect, to my knowledge. Builtin_expect will leave branch prediction hints, but won't remove the branch. This would remove the branch. There was a

I've proposed removing the llvm.expect intrinsic: http://reviews.llvm.org/D19300 The motivation for this change is in: http://reviews.llvm.org/D19299 For reference: 1. We created an intrinsic that's only reason for existing is to improve perf, but the intrinsic can harm optimization by interfering with transforms in other passes. 2. To solve that, we created a pass to always transform

On 10/25/2017 12:10 PM, Evgeny Astigeevich via llvm-dev wrote: > > Hi Chandler, > > I ran the LNT benchmarks and SPEC2k6.train on AArch64 Cortex-A57. I > used revisions: Clang 316561, LLVM 316563. > > Options: -O3 -mcpu=cortex-a57 -fomit-frame-pointer > -fexperimental-new-pass-manager > > Regressions: execution time increase > > LNT > >

Hi Reid - The intent of D19299 is to remove all Clang refs to llvm.expect. Do you see any holes after applying that patch? On Fri, Apr 22, 2016 at 11:36 AM, Reid Kleckner <rnk at google.com> wrote: > Clang still appears to use llvm.expect. I think if you can show that it's > trivial to update clang with a patch, then yeah, moving back down to one > representation for this

( I don't know if it's allowed to ask such question, if not, please remind me. ) I know Intel implemented several static branch prediction mechanisms these years: * 80486 age: Always-not-take * Pentium4 age: Backwards Taken/Forwards Not-Taken * PM, Core2: Didn't use static prediction, randomly depending on what happens to be in corresponding BTB entry , according to agner's

On 10/25/2017 12:32 PM, Evgeny Astigeevich wrote: > > Hi Hal, > > I quickly checked the execution profile. It is real. The code changed > significantly. A number of the hottest regions changed. I’ll compare IRs. > Thanks. Obviously a 1000% execution performance regression seems problematic. -Hal > JFYI FreeBench/fourinarow time graph: >

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

Hi, I'm interested in whether or not there is a way of providing source-level annotations to help LLVM with optimizations, similar to VisualC++'s __assume facility (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx). As part of our PHP compiler (phpcompiler.org), it would be great to be able to annotate our generated C code with, for example, (var != NULL), or (var->type ==

I, of course, thought the ~100 lines added by D19299 was a reasonable trade for the ~800 lines removed in D19300. David Li (and anyone else following along), do you still like those patches after hearing this objection or should I abandon? On Fri, Apr 22, 2016 at 11:55 AM, Reid Kleckner <rnk at google.com> wrote: > Sorry, I didn't realize that was the clang side. > > I think

I'm look at some code that does something roughly like this if (a >= 10 && a < 20) { // do calculation } else if (a >= 30 && a < 40) { // do calculation } else if (a >= 50 && a < 60) { // do something } else if (a >= 70 && a < 80) { // do something } // some other code that got split based on whether we entered any of the

On Sun, Oct 23, 2011 at 1:11 AM, Chandler Carruth <chandlerc at google.com>wrote: > Ok, I think I have a working pass that is based much more on what we've > talked about here. The patch is attached. I'd love to commit it soon-ish and > then start tweaking it based on feedback from you, others, and looking at > how it actually works in the wild. After chatting briefly

On Oct 18, 2011, at 2:53 AM, Chandler Carruth wrote: > Hello, > > I'm working on basic-block placement optimizations based on branch probability information. I've run into a stumbling block though. One of the existing passes to do this, essentially a dead pass 'block-placement' operates on the IR, reordering the blocks of the function, and relying on the code generator

On Oct 20, 2011, at 9:56 AM, Chandler Carruth wrote: > A new patch is attached that is *much* less of a rough draft. Sorry for any confusion due to the early state of the patch. Thanks, Chandler. This is great stuff. > Still, I never intended this to be on-by-default at first. This is a starting point, that I hope can be improved into something that is on-by-default eventually, but

Hi, I would like to learn the details regarding what exactly PGO does for basic block layout/code placement optimizations in llvm. Could you please point me to some descriptions? Is it close to this paper (Karl Pettis and Robert C. Hansen. 1990. Profile guided code positioning. PLDI'90) http://perso.ensta-paristech.fr/~bmonsuez/Cours/B6-4/Articles/papers15.pdf? Whether it is purely

On Oct 18, 2011, at 3:07 PM, Chandler Carruth wrote: > On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com> wrote: > I think this should really live as a CodeGen pass. Is there any good reason to make it an IR pass? > > So, as it happens, I was *completely* wrong here. CodeGen correctly preserves the ordering of blocks from IR, *unless* it can do folding,

I'm concerned that we're focusing on one side of this.  Let me point out a few concerns w/changing the canonical form here: 1. LICM does not know how to hoist or sink regions.  It does know how to hoist and sink selects. 2. InstCombine has limited support for triangles/diamonds, but fairly extensive support for selects. 3. EarlyCSE and GVN do not know how to eliminate fully

On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> As for why it should be an IR pass, mostly because once the selection dag runs through the code, we can never recover all of the freedom we have at the IR level. To start with, splicing MBBs around requires known about the terminators (which we only some of the time do), and it requires re-writing them a touch to account for the