similar to: Computing block profile weights

In include/llvm/ADT/Statistic.h, the identifier “DEBUG_TYPE” is never defined. I’ve noticed it’s defined as different things in a few other header files, including llvm/Analysis/BlockFrequencyInfoImpl.h, llvm/Analysis/RegionInfoImpl.h, llvm/Support/UnicodeCharRanges.h, llvm/Transforms/InstCombine/InstCombineWorkList.h, and llvm/Transforms/Utils/SSAUpdaterImpl.h. Should I edit Statistic.h so that

Hi, we got the following assert: assert(!Working[0].isLoopHeader() && "entry block is a loop header"); [in BlockFrequencyInfoImpl<BT>::tryToComputeMassInFunction(), BlockFrequencyInfoImpl.h] on a Hexagon target - the entry block is a loop header. Has someone seen this assert on other targets? What would be a preferable way to fix it: - extend BlockFrequency pass to

> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote: >> >> Hi, we got the following assert: >> >> assert(!Working[0].isLoopHeader() && "entry block is a loop header"); >> >> [in

On Feb 4, 2014, at 4:36 PM, Andrew Trick <atrick at apple.com> wrote: > > On Feb 4, 2014, at 4:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> 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: >>>

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 like this: clang input.bc -fprofile-generate -o

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

(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

This idea came up a few times recently [1][2] so I’d like start prototyping it. To summarize, we can emit optimization remarks using the -Rpass* options. These are currently emitted by optimizations like vectorization[3], unrolling, inlining and since last week loop distribution. For large programs however this can amount to a lot of diagnostics output to sift through. Filtering this by the

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>

I tried getting profile data from LLVM 3.1, using the method mentioned below. I tried it out on a simple matrix multiplication program. However, I noticed the following problems: 1. There is a warning message: "WARNING: profile information is inconsistent with the current program!" 2. The basic block counts (obtained from ProfileInfo::getExecutionCount(const BasicBlock*)) are

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: >

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

> On Feb 24, 2015, at 3:31 PM, Diego Novillo <dnovillo at google.com> wrote: > > > We (Google) have started to look more closely at the profiling infrastructure in LLVM. Internally, we have a large dependency on PGO to get peak performance in generated code. > > Some of the dependencies we have on profiling are still not present in LLVM (e.g., the inliner) but we will

Hi Apala, On 11/09/12 11:20, apala guha wrote: > 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()?) 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

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, 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

Dear Duncan, Thank you a lot for your feedback. I have a problem though. The branch weights counters overflow in some files and thus I get incorrect numbers. Is there any way to find a workaround for that? Is is supposed to be a known bug or is it something that needs configuration on my part? Again, thank you a lot for your reply. Best Regards, Georgios Zacharopoulos 2016-02-03 18:23

Hi Apala, Dibyendu is correct that this is likely due to pass order, but things get a bit complicated with -O[1-9] or -std-compile-opts as they insert early passes *before* the profiling code. I recommend that you use identical optimizations to insert instrumentation and to load the profiling data. E.g.: opt -insert-edge-profiling -O3 foo.bc -o foo.2.bc opt -profile-loader -O3 foo.bc

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

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,

> On 2014 Jun 17, at 21:59, Owen Anderson <resistor at mac.com> wrote: > > Hi Duncan, > > Some of these don’t make a lot of sense: Sorry -- I think I was assuming too much knowledge about what I committed as part of the BlockFrequencyInfo rewrite. What's committed there is a class called UnsignedFloat that wraps the following with a bunch of API: template