search for: builtin_expect

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++&...

...raction? In particular, the expect lowering > overrules any metadata on the associated branch/switch. This is exactly > what you'd expect for a user annotation interacting with PGO data. > I agree that a user annotation should override PGO data. This is why I initially proposed that builtin_expect() would extend on '[un]predictable' metadata rather than 'prof' metadata in D19299. But I think that's a separate discussion now; we use 'prof' metadata for this purpose today, and I'm not trying to change that in these patches. If the user-specified representation...

...t, we created a pass to always transform the intrinsic into metadata at a very early stage in LLVM. But now every program is paying a compile-time tax (running the LowerExpectIntrinsic pass) for a feature that is rarely used. A possible front-end replacement transformation for a source-level "builtin_expect()" is in D19299: I think a front-end can always directly create metadata for this kind of programmer hint rather than using an intermediate representation (the intrinsic). Likewise, if there's some out-of-tree IR pass that is creating an llvm.expect, it should be able to create branch weig...

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 discussion of adding this to GCC a long time ago (http://gcc.gn...

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 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 previously. 3) It completes a significant missing feature in LLVM with builtin_expect. 4) It "fixes" some of the regressions introduced with the inlining work by more effectively ensuring the loops are laid out correctly. (yacr2 specifically exhibited this problem) 5) I see more positive movement in performance than negative, but that may be an artifact of the testing I...

...grammers(with compiler) are usually the best guide. Of course these situations are usually not performance bottleneck, because once a branch is frequently executed, the dynamic predictor will capture it. Since Intel no longer clearly statements the dynamic prediction mechanism in its document, the builtin_expect() of GCC can do nothing more than removing the unlikely branch from hot path or reversely for likely branch. I am not familiar with CPU design and I don't know what exactly mechanism Intel use nowadays for its static predictor, I just feel the best static mechanism for Intel should be to clear...

...c >> into metadata at a very early stage in LLVM. But now every program is >> paying a compile-time tax (running the LowerExpectIntrinsic pass) for a >> feature that is rarely used. >> >> A possible front-end replacement transformation for a source-level >> "builtin_expect()" is in D19299: I think a front-end can always directly >> create metadata for this kind of programmer hint rather than using an >> intermediate representation (the intrinsic). Likewise, if there's some >> out-of-tree IR pass that is creating an llvm.expect, it should be...

...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 previously. > 3) It completes a significant missing feature in LLVM with builtin_expect. > 4) It "fixes" some of the regressions introduced with the inlining work by more effectively ensuring the loops are laid out correctly. (yacr2 specifically exhibited this problem) > 5) I see more positive movement in performance than negative, but that may be an artifact of the te...

Hello :) I am looking around __builtin_expect() directive for optimization. ( http://llvm.org/docs/BranchWeightMetadata.html ) Since it is not included in v2.9, I am searching about it on svn trunk. I found that the lowering phase generates branch-weight metadata node for that directive. However, I can't find any code related to the metad...

...stage in LLVM. But now every program is >>>> paying a compile-time tax (running the LowerExpectIntrinsic pass) for a >>>> feature that is rarely used. >>>> >>>> A possible front-end replacement transformation for a source-level >>>> "builtin_expect()" is in D19299: I think a front-end can always directly >>>> create metadata for this kind of programmer hint rather than using an >>>> intermediate representation (the intrinsic). Likewise, if there's some >>>> out-of-tree IR pass that is creating an l...

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

...this is going to sound very strange, but I think that we need to understand a bit more about how this is being handled. A while back one of my customers asked me if there was a method for advising the compiler how an if-statement was likely to resolve, and I said “sure” and told them to use ‘__builtin_expect’. At the time I thought that the compiler was probably predicting a higher probability or true/false than was actually the case for a particular instance, as my customer was telling me that the compiler was optimising in favour of the less probable case (something the customer knew, but the inf...

...as a tool to reduce code size while maintaining code performance. Our proposal is to improve on the existing outlining scheme of the partial inliner to give us more opportunities to inline hot code. We will only do this type of general outlining with the presence of profiling or user data (such as builtin_expect). With that said, I am interested in how River plans to handle live ranges and heuristics he will use with profiling data available. I haven't looked at the machine outliner yet, but my understanding is it also prioritizes code size reduction over performance gains. Is my assumption correct?...

...me > performance. > > >> Our proposal is to improve on the existing outlining scheme of the >> partial inliner to give us more opportunities to inline hot code. We will >> only do this type of general outlining with the presence of profiling or >> user data (such as builtin_expect). >> > With that said, I am interested in how River plans to handle live ranges >> > > It's a pretty difficult problem. I have estimation for register usage > within an outlined region, using something similar to the register cost > calculation in the loop vectorizer...

...ld code indicator. In the past I have used it to measure coldness in two ways, which seemed to work ok, but I admit it’s not a great system: > (1) Identify almost never taken code using a very small fraction (say 2^-10). This looks like it won’t work well for us though with static heuristics and builtin_expect. > (2) Compare the frequency relative to the enclosing loop header, e.g. to move “cold” stuff out of the loop. > > -Andy To resurrect this thread, I just posted a patch series on llvm-commits [1] that replaces the block frequency calculation with a new algorithm. [1]: http://lists.cs.ui...

On Feb 3, 2014, at 12:13 AM, Andrew Trick <atrick at apple.com> wrote: > On Feb 2, 2014, at 6:55 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > >> On Sun, Feb 2, 2014 at 6:18 PM, Andrew Trick <atrick at apple.com> wrote: >> >> On Feb 2, 2014, at 2:13 AM, Chandler Carruth <chandlerc at gmail.com> wrote: >> >> > Right now,

Hello, My team and I are looking to do some enhancements in the partial inliner in opt. Would appreciate any feedback that folks might have. # Partial Inlining in LLVM opt ## Summary ### Background Currently, the partial inliner searches the first few blocks of the callee and looks for a branch to the return block (ie. early return). If found, it attempts to outline the rest of the