[LLVMdev] counting branch frequencies

[apala guha]

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