search for: blockfrequencyinfo

Hey, I am trying to use the BlockFrequencyInfoWrapperPass to obtain hotness information in my LLVM pass. Attached is a minimal example of code which creates a SIGSEGV. The pass calls AU.addRequired<BlockFrequencyInfoWrapperPass>(); in getAnalysisUsage(..). The problem exists with changed and unchanged IR. The binary is instrumented l...

Hello, I'm working on an application that would benefit from knowing the weight of a basic block, as in "fraction of the program's execution time spent in this block". Currently, I'm computing this using the block's frequency from BlockFrequencyInfo, relative to the function's entry block frequency, and scaled by the function's entry count. This is also the computation that's done by getBlockProfileCount <https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/BlockFrequencyInfoImpl.cpp#L540> in lib/Analysis/BlockFrequen...

Hi all, To implement more profile-guided optimizations, we’d like to use ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of various types, under the new pass manager. The following is what we came up with. Would appreciate feedback. Thanks. Issue It’s not obvious (to me) how to best do this, given that we cannot request an outer-scope analysis result from an inner-scope pass through analysis...

(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

...ocus the user on performance opportunities that are likely to pay off. The approach I am thinking of taking is to install a wrapper as the diagnostics handler that will only forward to the original handler if the region of code is considered hot. This will be installed by a new pass that will use BlockFrequencyInfo to determine the top N hot regions. This is at very early stage right now. I would appreciate any feedback. Thanks, Adam [1] http://lists.llvm.org/pipermail/llvm-dev/2016-April/098492.html [2] http://lists.llvm.org/pipermail/cfe-dev/2016-April/048526.html [3] http://blog.llvm.org/2014/11/loop-v...

...: 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 information. Even the other analysis is merely built on top of this one. Second we have BlockFrequencyInfo which attempts to provide a more "global" (function-wide, not actually program wide) view of the statistical frequency with which any particular basic block is executed. This is nicely principled analysis that just computes the probabilistic flow of control through the various branches ac...

...present an execution count. This makes things like comparing hotness across functions hard or impossible. We need a concept of global hotness. The plan that we have discussed in the past (I don’t remember when) was to record simple function entry execution counts. Those could be combined with the BlockFrequencyInfo to compare “hotness” across functions. > When the CFG or callgraph change, there need to exist an API for incrementally updating/scaling counts. For instance, when a function is inlined or partially inlined, when the CFG is modified, etc. These counts need to be updated incrementally (or perhaps...

...Hi all, >>>>> >>>>> To implement more profile-guided >>>>> optimizations, we’d like to use >>>>> ProfileSummaryInfo (PSI) and >>>>> BlockFrequencyInfo (BFI) from more passes of >>>>> various types, under the new pass manager. >>>>> >>>>> The following is what we came up with. Would >>>>> appreciate feedback. Thanks. >>>...

...54 PM Fedor Sergeev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: >> >> Hi all, >> >> To implement more profile-guided optimizations, we’d like to use >> ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of >> various types, under the new pass manager. >> >> The following is what we came up with. Would appreciate feedback. Thanks. >> >> Issue >> >> It’s not obvious (to me) how to best do this, given that we cannot >> request an...

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>

...) > > > Profile data really needs to be loaded at a module level, but once > this has been done it can be accessed at any level (including function). > > In LLVM 3.1 ProfileInfo stores block execution frequencies (use > -profile-loader). > > For LLVM svn you can look at BlockFrequencyInfo, which I generates its > data from BranchFrequencyInfo, which in turn uses the branch weight > metadata (set by -profile-metadata-loader). I haven't actually tried > this though, so I'm not sure how accurately the block frequencies are > maintained. > > >> Also,...

...lock > frequencies in runOnFunction()?) Profile data really needs to be loaded at a module level, but once this has been done it can be accessed at any level (including function). In LLVM 3.1 ProfileInfo stores block execution frequencies (use -profile-loader). For LLVM svn you can look at BlockFrequencyInfo, which I generates its data from BranchFrequencyInfo, which in turn uses the branch weight metadata (set by -profile-metadata-loader). I haven't actually tried this though, so I'm not sure how accurately the block frequencies are maintained. > Also, I was able to produce a 'll...

...;> >> On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: >>> Hi all, >>> >>> To implement more profile-guided optimizations, we’d >>> like to use ProfileSummaryInfo (PSI) and >>> BlockFrequencyInfo (BFI) from more passes of various >>> types, under the new pass manager. >>> >>> The following is what we came up with. Would appreciate >>> feedback. Thanks. >>> >>> Issue >>> >>&gt...

...58845 On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: > > Hi all, > > To implement more profile-guided optimizations, we’d like to use > ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of > various types, under the new pass manager. > > The following is what we came up with. Would appreciate feedback. Thanks. > > Issue > > It’s not obvious (to me) how to best do this, given that we cannot request > an outer-scope analysis result from...

Thanks Alastair. Is it possible to associate the branch frequency counts with the basic blocks in the intermediate representation? (e.g. Can I access basic block frequencies in runOnFunction()?) Also, I was able to produce a 'llvmprof.out' file. What is the format of this file? How can I parse it? Thanks. -Apala > > > On 09/07/2012 01:25 PM, Alastair Murray wrote: >

...make them preserve BFI > through. This is to avoid pipeline interruptions and potential > invalidation/recomputation of BFI between the loop passes. We detect > PGO based on whether PSI has profile summary info. (For the old pass > manager, implement a similar approach by using LazyBlockFrequencyInfo.) There is already an optional analysis in LoopStandardAnalysisResults - MemorySSA. We can do the same for BFI/BPI. And, yes - preserving those through loop passes is a cornerstone to this approach. > > - Add a new proxy ModuleAnalysisManagerLoopProxy for a loop pass to be > able to get...

...would have sent this to llvm-dev at lists.llvm.org (and > CC'ed me) so that the answer is there for others to find in the > archive. If you have any follow-up questions, please add llvm-dev > to the CC list.) > > Assuming you already have branch weights, you should use the > BlockFrequencyInfo analysis to calculate the block frequencies. At > the Machine level, there's a MachineBlockFrequencyInfo analysis. > > The frequencies shouldn't be used in isolation, but with reference > to each other. > > Cheers, > Duncan > > > On 2016-Feb-03, at 00:43, Gior...

...le data really needs to be loaded at a module level, but once >> this has been done it can be accessed at any level (including function). >> >> In LLVM 3.1 ProfileInfo stores block execution frequencies (use >> -profile-loader). >> >> For LLVM svn you can look at BlockFrequencyInfo, which I generates its >> data from BranchFrequencyInfo, which in turn uses the branch weight >> metadata (set by -profile-metadata-loader). I haven't actually tried >> this though, so I'm not sure how accurately the block frequencies are >> maintained. >> &gt...

...ilities. 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 information. Even the other > analysis is merely built on top of this one. > > > > Second we have BlockFrequencyInfo which attempts to provide a more > "global" (function-wide, not actually program wide) view of the statistical > frequency with which any particular basic block is executed. This is nicely > principled analysis that just computes the probabilistic flow of control > through the...

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