<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 18, 2020 at 5:48 PM Wenlei He via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">wenlei added a subscriber: hoy.<br>
wenlei added a comment.<br>
<br>
> We record function entry count and branch weights and use them to compute the count when needed. This mechanism works well in a perfect world, but often breaks in real programs<br>
<br>
We're battling this exact problem from sample PGO side. And we have internal patches for comparing block counts from BFI with ground truth. Perhaps these all can be refactored to be shared between Instr PGO and sample PGO. +@hoy<br>
<br>
How does fixing up entry count alone help mitigate this problem?<br></blockquote><div>As I mentioned earlier in this review, the raw profile is inconsistent and the information is not sufficient to recover the loss. Nevertheless, the probabilities for most of the branches are OK. BFI uses  the entry counter and all the individual branch probability to compute the BFI. We don't want to touch branch probability as they are set in the counter propagation stage with the best information they have. Here we adjust the entry counter to make the BFI count and raw count closer. I think that's probably the best we can do.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D61540/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D61540/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D61540" rel="noreferrer" target="_blank">https://reviews.llvm.org/D61540</a><br>
<br>
</blockquote></div></div>