[LLVMdev] counting branch frequencies
aguha at uchicago.edu
Wed Sep 19 08:58:28 PDT 2012
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 supposed to return the function invocation count?
If my assumption is not wrong, is there any way to fix the results?
On 09/19/2012 09:53 AM, apala guha wrote:
> 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
> Anyone else have this experience? Or, any ideas why the above might
> On 09/19/2012 08:49 AM, Alastair Murray wrote:
>> 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.
>> opt -insert-edge-profiling -O3 foo.bc -o foo.2.bc
>> opt -profile-loader -O3 foo.bc -o foo.opt.bc
>> (The same applies to -profile-metadata-loader.) The -O3 on the first
>> line seems pointless, but without it the CFG will be different (due
>> to the early passes it inserts which run before any user specified
>> I've been thinking about submitting a patch to also include profile
>> passes in the early passes (it they are turned on), but that seems
>> quite limiting (a user may want to run them after other passes).
>> This should fix all your problems (I hope!). Problem 1 means the
>> program CFG does not match and thus the profiling data is basically
>> gibbberish (hence problems 2 and 3). Perhaps that is another patch:
>> fail on this condition rather than just warn.
>> Hope this helps,
>> On 18/09/12 15:03, apala guha wrote:
>>> 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.
>>> 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
>>>>> 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
>>>> In LLVM 3.1 ProfileInfo stores block execution frequencies (use
>>>> 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
>>>>> 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.
More information about the llvm-dev