similar to: [LLVMdev] RFC: Profiling Enhancements (GSoC)

Hi Alastair, In addition to your planned tasks, you might want to put in some work to ensure branch probabilities are not lost during optimization. One known issue is LLVM optimizer can turn branchy code into switch statements and it would completely discard probability. Here is a simple example: static void func2(int N, const int *a, const int *b, int *c) __attribute__((always_inline)); void

On Sun, Jul 15, 2012 at 8:32 AM, Alastair Murray <alastairmurray42 at gmail.com > wrote: > 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.

Dear List: I have the following simple program: x<- sample(site) VarGuilda1<- var(tapply(x,site,func1)) VarGuilda2<- var(tapply(x,site,func2)) VarGuilda3<- var(tapply(x,site,func3)) VarGuilda4<- var(tapply(x,site,func4)) VarGuilda5<- var(tapply(x,site,func5)) VarGuilda6<- var(tapply(x,site,func6)) VarGuilda7<- var(tapply(x,site,func7)) VarGuilda8<-

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

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 Chandler and Alastair, I have been using the Profile.pl and the related passes and optimizations for about 4 years now. With every new release lately, the support for the profile scripts and their framework seemed to be downgrading. Hence, I used my own tiny one line fixes to keep them working. I offered to send these small patches to keep these scripts working, to the LLVM dev so that others

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

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

Thanks everyone for the replies. After some experimentation, I found that the order in which the passes are specified matters: opt -O3 -profile-loader matmult.bc -o matmult.opt.bc (works) opt -profile-loader -O3 matmult.bc -o matmult.opt.bc (does not work) Also, I am able to avoid the inconsistency warning only for optimization levels -O3 and -O2. I get that warning when using -O1 and

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

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

Hi all, Attached is a draft patch to use profiling data to set branch weight metadata. I'm not formally submitting this as a patch yet as it does not make much sense to add it before ProfileInfo etc. is removed. I am, however, interested in making sure this is the correct approach to be taking, or any other feedback. (Also, there are a few TODO notes in there which would not be in the

Another issue is with ProfileInfo::getExecutionCount(Function* F). Looking at the source code and results, I am seeing that it always returns the execution count of the entry basic block of the function. If the entry basic block is part of a loop, its execution count does not match the function invocation count. Is my assumption wrong, that ProfileInfo::getExecutionCount(Function* F) is

Hi Alastair, Your patch looks great. I am new on this part of llvm. Why do we want to get rid of ProfileInfo? Is there any email thread related to this? I understand that we want to setBranchWeightMetadata from the profiling data generated by -insert-edge-profiling. I thought the existing loader can parse the profiling data and map the data to the IR, and only the setting of metadata is missing.

Can we not run the -insert-edge-profiling and -profile-loader passes at the beginning of the opt? Orthogonal point is, is it worth doing any optimizations when -insert-edge-profiling is specified on command line? -Prashantha -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alastair Murray Sent: Wednesday, September 19, 2012

Hi Alok, On 16/07/12 12:41, #ALOK PRAKASH# wrote: > I have been using the Profile.pl and the related passes and > optimizations for about 4 years now. With every new release lately, the > support for the profile scripts and their framework seemed to be > downgrading. Hence, I used my own tiny one line fixes to keep them > working. I offered to send these small patches to keep these

Alright, I'm ready to nuke it. Last chance to say stop. For context of others, this has come up repeatedly: no one we know of is using EdgeProfiling.cpp, PathProfiling.cpp, and the lib/Analysis/Profile*Pass.cpp collection of tools. They haven't been updated since 2012 when Alastair Murray looked into this stuff, and both current efforts towards PGO are essentially *totally* different

Hey all, I have a piece of code (written in LLVM 2.8) which uses profiling results produced by ProfileInfo. It essentially computes the number of iterations performed by a loop from the profiling information available. The code snippet in my pass looks something like this. BasicBlock *header = loop->getHeader(); ProfileInfo &pi = getAnalysis< ProfileInfo >(); for(pred_iterator

Thank you so much for your response. On Wed, Aug 15, 2018 at 3:08 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Wed, Aug 15, 2018 at 7:36 AM Malhar Thakkar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hey all, >> >> I have a piece of code (written in LLVM 2.8) which uses profiling results >> produced by ProfileInfo.

On Wed, Aug 15, 2018 at 1:28 PM Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Wed, Aug 15, 2018 at 12:46 PM Malhar Thakkar <cs13b1031 at iith.ac.in> > wrote: > >> Thank you so much for your response. >> >> On Wed, Aug 15, 2018 at 3:08 PM, Xinliang David Li <xinliangli at gmail.com> >> wrote: >> >>> >>>