[LLVMdev] counting branch frequencies

apala guha aguha at uchicago.edu
Tue Sep 18 12:03:33 PDT 2012

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 correct only if I 
have compiled with "-disable-opt" or "-O0". When compiled with "-O3", 
the basic block counts are bogus values.
3. Some of the function counts (obtained from 
ProfileInfo::getExecutionCount(const Function*)) are incorrect i.e. they 
do not equal the number of times the function was invoked.

Can someone please explain why I am experiencing the above problems? 
Thanks in advance!


On 09/12/2012 09:20 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 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 'llvmprof.out' file. What is the format of
>> this file? How can I parse it?
> Very roughy the format of the file is lots of unsigned integers. 
> -profile-loader or -preofile-metadata-loader will parse it for you. 
> Parsing outside of LLVM is tricky as it relies on exact ordering of 
> basic blocks.
> Regards,
> Alastair.

More information about the llvm-dev mailing list