[llvm-dev] Profiling with LLVM.

Sun Feb 7 03:44:50 PST 2016

Dear David,

Thank you a lot for clarifying all these points. Yes, I was also thinking
that the final block profile count should be equal to the computed
frequency data (floating point number) of each Basic Block multiplied with
the entry count of the respective function.

In case I come across any unexpected behaviour in the future I will notify
the llvm-bugs list.

Best Regards,
Georgios Zacharopoulos

2016-02-05 18:07 GMT+01:00 Xinliang David Li <xinliangli at gmail.com>:

>
>
> On Fri, Feb 5, 2016 at 5:40 AM, Giorgio Zacharo via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Dear Duncan,
>>
>> I am generating branch-weights annotated IR files as described in the
>> documentation of LLVM, using profiling with instrumentation.
>> http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation
>>
>> e.g.
>>
>> llvm-profdata merge -output=$(BENCH).profdata default.profraw
>>> clang -S -emit-llvm -O3 -fprofile-instr-use=$(BENCH).profdata -o
>>> bench.prof.ll bench.c
>>
>>
>> The issue is that in some benchmarks I get crazy numbers in the annotated
>> metadata inside the generated *.ll files.
>>
>> e.g.
>>
>> !16 = !{!"branch_weights", i32 -2147483648, i32 0}
>>> !155 = !{!"branch_weights", i32 1075807200, i32 -1501637297}
>>> !181 = !{!"branch_weights", i32 -965299388, i32 218980800}
>>
>>
>
>>
>> This should be a counter overflow.
>>
>>
> It is not counter overflow. Branch weights are not the same as branch
> profile counts. Branch weights are intended to represent branch probability
> and the absolute value of 'weight' does not mean anything. For branch
> weights that come from real profile data, they may look like real profile
> counts if not scaled.  The negative value is a problem in dumping -- it
> should be printed as uint32.
>
> In fact, BPI and MBPI no longer have weight based interfaces (since the
> concept of weight is confusing). However 'weight' remains in the meta data
> representation.
>
>
>
>> Now the interesting thing is that by using these annotated files as input
>> for the BasicBlockFrequency analysis pass,the output seems to give correct
>> numbers, regarding the Frequency execution of each Basic Block, even though
>> few of the counters have overflowed.
>>
>
> The correct frequency information is expected except for a couple of known
> cases where block frequency propagation does not work well. For instance
> handling irreducible loops, infinite loops (in general branch with zero
> weights) etc.
>
> To get the real block and edge/branch profile count, you should look at
> the computed frequency data and combine it with function's
> 'function_entry_count' meta data. The later is the real profile count of
> the entry block.
>
>
>>
>> This seems like a bug, unless I need to do specific configurations while
>> running the profiling part before the analysis.
>> From your experience, would you say that the BasicBlockFrequency analysis
>> pass output is to be trusted? Is it known to be stable or do I need to be
>> really cautious and always inspect the output? Are there any common cases
>> of not having accurate profiling?
>>
>
> For common cases, it should be trusted. If you see problems, please file
> bugs.
>
> thanks,
>
> David
>
>
>
>>
>> As I mentioned earlier, the analysis pass seems fine to me, but I have
>> only tested it for a number of benchmarks.
>>
>> Best Regards.
>> Georgios Zacharopoulos
>>
>> 2016-02-04 18:13 GMT+01:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>
>> :
>>
>>> It's up to the frontend (or whatever is generating the branch weights
>>> metadata) to scale the branch weights down appropriately.  You can have a
>>> look at how clang does it for an example (IIRC, it's in clang's
>>> lib/CodeGen/CodeGenPGO.cpp, but possibly just the caller is there and the
>>> scaling logic is somewhere in LLVM).
>>>
>>> When are your counters overflowing?  If they overflow during an
>>> optimization pass, that sounds like a bug.
>>>
>>> > On 2016-Feb-04, at 05:51, Giorgio Zacharo <giorgiozacharo at gmail.com>
>>> wrote:
>>> >
>>> > Dear Duncan,
>>> >
>>> > Thank you a lot for your feedback. I have a problem though. The branch
>>> weights counters overflow in some files and thus I get incorrect numbers.
>>> > Is there any way to find a workaround for that? Is is supposed to be a
>>> known bug or is it something that needs configuration on my part?
>>> >
>>> > Again, thank you a lot for your reply.
>>> >
>>> > Best Regards,
>>> > Georgios Zacharopoulos
>>> >
>>> > 2016-02-03 18:23 GMT+01:00 Duncan P. N. Exon Smith <
>>> dexonsmith at apple.com>:
>>> > (Ideally you would have sent this to llvm-dev at lists.llvm.org (and
>>> > CC'ed me) so that the answer is there for others to find in the
>>> > archive.  If you have any follow-up questions, please add llvm-dev
>>> > to the CC list.)
>>> >
>>> > Assuming you already have branch weights, you should use the
>>> > BlockFrequencyInfo analysis to calculate the block frequencies.  At
>>> > the Machine level, there's a MachineBlockFrequencyInfo analysis.
>>> >
>>> > The frequencies shouldn't be used in isolation, but with reference
>>> > to each other.
>>> >
>>> > Cheers,
>>> > Duncan
>>> >
>>> > > On 2016-Feb-03, at 00:43, Giorgio Zacharo <giorgiozacharo at gmail.com>
>>> wrote:
>>> > >
>>> > > Dear Duncan,
>>> > >
>>> > > My name is Georgios Zacharopoulos and I am a PhD student at
>>> University of Lugano, in Switzerland. I am currently working on a research
>>> project and for a part of it I need to use some profiling information
>>> generated by existing LLVM tools from the latest version of LLVM. In more
>>> detail, I am trying to map profiling information generated from LLVM
>>> (Profiling with instrumentation) to IR.
>>> > > (
>>> http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation
>>> )
>>> > >
>>> > > Specifically, I want to annotate each Basic Block with its
>>> respective execution frequency. In order to accomplish that I am using the
>>> branch weight metadata annotated to conditional branches in the terminator
>>> instructions of Basic Blocks. These branch weight information as well as
>>> the entry counter of each function are generated by the already existing
>>> profiling tools of LLVM.
>>> > >
>>> > > Are you aware of such frequency annotation for each BB already
>>> existing? Do you know whether this is feasible using the information of the
>>> branch weights and the entry counters of functions? I want to verify that I
>>> am doing it in the correct way, but unfortunately I have not come up with a
>>> clean way to do this. If you could give me any tips regarding that, it
>>> would be extremely helpful to me.
>>> > >
>>> > > Thank you a lot in advance.
>>> > >
>>> > > --
>>> > > Best Regards,
>>> > > Georgios Zacharopoulos
>>> > >
>>> > > PhD student
>>> > > Faculty of Informatics
>>> > > Università della Svizzera italiana
>>> > > Lugano, Switzerland
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Best Regards,
>>> > Georgios Zacharopoulos
>>> >
>>> > PhD student
>>> > Faculty of Informatics
>>> > Università della Svizzera italiana
>>> > Lugano, Switzerland
>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Georgios Zacharopoulos
>>
>> PhD student
>> Faculty of Informatics
>> Università della Svizzera italiana
>> Lugano, Switzerland
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>

-- 
Best Regards,
Georgios Zacharopoulos

PhD student
Faculty of Informatics
Università della Svizzera italiana
Lugano, Switzerland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160207/e998a74e/attachment-0001.html>