[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!
-Apala
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