<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 5:40 AM, Giorgio Zacharo via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Duncan,<div><br></div><div>I am generating branch-weights annotated IR files as described in the documentation of LLVM, using profiling with instrumentation.</div><div><a href="http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation" target="_blank">http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation</a><br></div><div><br></div><div>e.g.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">llvm-profdata merge -output=$(BENCH).profdata default.profraw<br>clang -S -emit-llvm -O3 -fprofile-instr-use=$(BENCH).profdata -o bench.prof.ll bench.c</blockquote><div><br></div><div>The issue is that in some benchmarks I get crazy numbers in the annotated metadata inside the generated *.ll files.</div><div><br></div><div>e.g.</div><div><span><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>!</span><span>16</span><span> = !{!</span><span>"branch_weights"</span><span>, i32 </span><span>-<a href="tel:2147483648" value="+12147483648" target="_blank">2147483648</a></span><span>, i32 </span><span>0</span><span>}<br></span><span>!</span><span>155</span><span> = !{!</span><span>"branch_weights"</span><span>, i32 </span><span>1075807200</span><span>, i32 </span><span>-1501637297</span><span>}</span> <br><span>!</span><span>181</span><span> = !{!</span><span>"branch_weights"</span><span>, i32 </span><span>-965299388</span><span>, i32 </span><span>218980800</span><span>}</span></blockquote></div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>This should be a counter overflow.</div><div><br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>This seems like a bug, unless I need to do specific configurations while running the profiling part before the analysis.</div><div>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?</div></div></blockquote><div><br></div><div>For common cases, it should be trusted. If you see problems, please file bugs.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>As I mentioned earlier, the analysis pass seems fine to me, but I have only tested it for a number of benchmarks.</div><div><br></div><div>Best Regards.</div><div>Georgios Zacharopoulos</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-02-04 18:13 GMT+01:00 Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).<br>
<br>
When are your counters overflowing? If they overflow during an optimization pass, that sounds like a bug.<br>
<div><div><br>
> On 2016-Feb-04, at 05:51, Giorgio Zacharo <<a href="mailto:giorgiozacharo@gmail.com" target="_blank">giorgiozacharo@gmail.com</a>> wrote:<br>
><br>
> Dear Duncan,<br>
><br>
> 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.<br>
> 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?<br>
><br>
> Again, thank you a lot for your reply.<br>
><br>
> Best Regards,<br>
> Georgios Zacharopoulos<br>
><br>
> 2016-02-03 18:23 GMT+01:00 Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>>:<br>
> (Ideally you would have sent this to <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> (and<br>
> CC'ed me) so that the answer is there for others to find in the<br>
> archive. If you have any follow-up questions, please add llvm-dev<br>
> to the CC list.)<br>
><br>
> Assuming you already have branch weights, you should use the<br>
> BlockFrequencyInfo analysis to calculate the block frequencies. At<br>
> the Machine level, there's a MachineBlockFrequencyInfo analysis.<br>
><br>
> The frequencies shouldn't be used in isolation, but with reference<br>
> to each other.<br>
><br>
> Cheers,<br>
> Duncan<br>
><br>
> > On 2016-Feb-03, at 00:43, Giorgio Zacharo <<a href="mailto:giorgiozacharo@gmail.com" target="_blank">giorgiozacharo@gmail.com</a>> wrote:<br>
> ><br>
> > Dear Duncan,<br>
> ><br>
> > 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.<br>
> > (<a href="http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation" rel="noreferrer" target="_blank">http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation</a>)<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > Thank you a lot in advance.<br>
> ><br>
> > --<br>
> > Best Regards,<br>
> > Georgios Zacharopoulos<br>
> ><br>
> > PhD student<br>
> > Faculty of Informatics<br>
> > Università della Svizzera italiana<br>
> > Lugano, Switzerland<br>
><br>
><br>
><br>
><br>
> --<br>
> Best Regards,<br>
> Georgios Zacharopoulos<br>
><br>
> PhD student<br>
> Faculty of Informatics<br>
> Università della Svizzera italiana<br>
> Lugano, Switzerland<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Best Regards,<div>Georgios Zacharopoulos</div><div><br></div><div><font size="1" face="georgia, serif">PhD student</font></div><div><font size="1" face="georgia, serif">Faculty of Informatics </font></div><div><font size="1" face="georgia, serif">Università della Svizzera italiana</font></div><div><font size="1" face="georgia, serif">Lugano, Switzerland</font></div></div></div></div></div></div></div></div></div></div></div>
</div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>