search for: branchprobabilityinfo

Adding Maxim On Apr 9, 2018, at 10:06 AM, Sam Parker via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi, extractRangeChecksFromBranch uses BranchProbabilityInfo to decide whether its worth trying the InductiveRangeCheckElimination transformation. For the following example: void split() { for (int i = 0; i < 100; ++i) { if (i < 99) do_something() else do_something_else() } } But the reported BPI is reported as 50/50 to whethe...

Hi, extractRangeChecksFromBranch uses BranchProbabilityInfo to decide whether its worth trying the InductiveRangeCheckElimination transformation. For the following example: void split() { for (int i = 0; i < 100; ++i) { if (i < 99) do_something() else do_something_else() } } But the reported BPI is reported as 50/50 to whethe...

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 metadata even in the branch transformation code. IMHO, in

...frequencies, we don't really need 64bits, as they're just > comparative values that can be squished into 32bits. It's the branch > weights being 32 bit quantities that are throwing off the calculations. Do you still see the issue after fixing bhe bug (limit without scaling) in BranchProbabilityInfo::calcMetadataWeights ? David > > > Diego.

...ose edge weights, because they have no independent meaning, we need a richer API. Example: BasicBlock *getHotSucc(BasicBlock *BB); bool isEdgeHot(BasicBlock *pred, BasicBlock *succ); The API will be implemented entirely using fixed point arithmetic. Example: class BranchProbability { friend BranchProbabilityInfo; unsigned numerator; unsigned denominator; BranchProbability(...); // no public ctor ... }; class BranchProbabilityInfo { static BranchProbability HotProb; static initProb(); ... }; void BranchProbabilityInfo::initProb() { HotProb = BranchProbability(4, 5); } bool isEdgeHot(src,...

...issues with the current system: my original proposal was > written without knowledge of the limitations. This is why this list > hasn't heard much from me yet. > It would be better to actually email the list with the problems you are hitting sooner. We would have directed you to the BranchProbabilityInfo and BlockFrequencyInfo infrastructure that is now actively in use by several optimization passes in LLVM. Can you start a thread with what your specific goals are? The only email I have from you is from May 1st, which was your project outline for the GSoC application, to which Evan responded, but...

Hi, Which optimization passes use profile information? http://llvm.org/docs/Passes.html seems to suggest only block placement uses it, is that correct? Emma. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/46cc3ccc/attachment.html>

Hi Chandler, I'm a GSoC student working on profiling support (mentor CC'ed). I'm no stranger to the issues with the current system: my original proposal was written without knowledge of the limitations. This is why this list hasn't heard much from me yet. I would like to continue working on profiling support but I'm not attached to ProfileInfo and wouldn't be

...stranger to the issues with the current system: my original proposal was written without knowledge of the limitations. This is why this list hasn't heard much from me yet. It would be better to actually email the list with the problems you are hitting sooner. We would have directed you to the BranchProbabilityInfo and BlockFrequencyInfo infrastructure that is now actively in use by several optimization passes in LLVM. Can you start a thread with what your specific goals are? The only email I have from you is from May 1st, which was your project outline for the GSoC application, to which Evan responded, but...

...tadata by profiling At the absolute minimum this will require writing a new profile loader which will set branch weight metadata based on profiling data. #1 Optionally use profiling support to heuristics within: * Loop unrolling * Loop unswitching * Inliner The existing BranchProbabilityInfo, and BlockFrequencyInfo are not used in Transforms/*/* at all, just in CodeGen/*. Is there a reason for this, or is it quite possible to use them in Transforms/*/* passes? The original plan was to test these using ProfileEstimator, now the static heuristics within BranchProbability could be u...

Hello folks, I'd like to remove all of the old and defunct profile info passes from LLVM. These have been almost entirely supplanted by the BranchProbability and BlockFrequency systems, which are actually on by default, and in use in optimization passes. The old system is not on, and hasn't been touched in years except to do minor build fixes and updates. As far as I'm aware, the

Hi, Anyone working to incorporate "real" profiles to lib/CodeGen/MachineBranchProbabilityInfo.cpp using profile-metadata-loader? We could use something similar to llvm's BranchProbabilityInfo. Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121008/cc8279c9/attachment.html>

Hello all, I was trying to use the profile estimator and ran into the following issue. An initial weight is assigned to a function entry in lib/Analysis/ProfileEstimator.cpp on line 340. In the code this weight is pow(2.0, 32.0) whereas the comment three lines up explains that this should be 1.0 Can someone fix this in trunk? (replacing 'pow(2.0, 32.0)' with '1.0' worked for

Hello llvmdevs, In a function pass, I need to visit all the basic blocks in bottom-up order (the exact opposite of ReversePostOrderTraversal). I noticed some APIs like po_iterator but wasn't able to figure out an example usage for this on web. Any pointers/suggestions are highly appreciated. Thanks, Ananth -------------- next part -------------- An HTML attachment was scrubbed... URL:

Right now, all profile information is funneled through two analysis passes prior to any part of the optimizer using it. First, we have BranchProbabilityInfo, which provides a simple interface to the simplest form of profile information: local and relative branch probabilities. These merely express the likelihood of taking one of a mutually exclusive set of exit paths from a basic block. They are very simple, and the foundation of the profile informatio...

(Resending after removing llvmdev at cs.uiuc.edu and using llvm-dev at lists.llvm.org) On Mon, Dec 7, 2015 at 3:08 PM, Easwaran Raman <eraman at google.com> wrote: > Hi Philip, > > Is there any update on this? I've been sending patches to get rid of the > callee hotness based inline hints from the frontend and move the logic to > the inliner. The next step is to use

Hi, I am planning to begin a project to explore the space of tuning LLVM internals in an effort to increase performance. I am wondering if anyone can point to me any parameterizations, heuristics, or priorities functions within LLVM that can be tuned/adjusted. So far, I'm considering BranchProbabilityInfo and InlineCost. Does anyone have any other suggestions? Thanks, Robert

...um this will require writing a new profile loader > which will set branch weight metadata based on profiling data. > > > #1 Optionally use profiling support to heuristics within: > * Loop unrolling > * Loop unswitching > * Inliner > > The existing BranchProbabilityInfo, and BlockFrequencyInfo are not used > in Transforms/*/* at all, just in CodeGen/*. Is there a reason for > this, or is it quite possible to use them in Transforms/*/* passes? The > original plan was to test these using ProfileEstimator, now the static > heuristics within BranchPr...

yes -- for count representation, 64 bit is needed. The branch weight here is different and does not needs to be 64bit to represent branch probability precisely. David On Fri, Apr 24, 2015 at 12:21 PM, Smith, Kevin B <kevin.b.smith at intel.com> wrote: > FWIW. Intel compiler's profile instrumentation uses 64 bit integer counters. > We wrestled with similar problems for a long

...ntially invalidates the analysis, >> so you have to rerun your analysis again and again. Hence instead of >> saving on compile time it ends up increasing it. >> > > Exactly. > > >> I have hit this issue somewhat recently with dependency of loop passes on >> BranchProbabilityInfo. >> (some loop passes, like IRCE can use it for profitability analysis). >> > The only solution that appears to be reasonable there is to teach all the >> loops passes that need to be pipelined >> to preserve BPI (or any other module/function-level analyses) similar to &g...