[LLVMdev] counting branch frequencies

[apala guha]

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?

Thanks.
-Apala


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 
> -disable-opt.
>
> Anyone else have this experience? Or, any ideas why the above might 
> happen?
>
> Thanks.
> -Apala
>
>
> 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.
>>
>> E.g.:
>> 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 
>> passes).
>>
>> 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,
>> Alastair.
>>
>> 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. 
>>> 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.
>>>
>>>
>>
>