<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;"><br></div></div><div>On Sep 1, 2016, at 18:23, Adam Nemet <<a href="mailto:anemet@apple.com">anemet@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>anemet added a comment.</span><br><span></span><br><span>In <a href="https://reviews.llvm.org/D24118#532156">https://reviews.llvm.org/D24118#532156</a>, @davidxl wrote:</span><br><span></span><br><blockquote type="cite"><span>There is a fundamental problem in BFI that it can not handle 0 weight -- to workaround it</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>1. FE PGO annotator will always add 1 to weights of both targets unconditionally when annotating the branch</span><br></blockquote><blockquote type="cite"><span>2. BFI always add 1 to the weight if it is zero.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> The end result is that</span><br></blockquote><blockquote type="cite"><span>3. we will never see code region annoated with zero frequency/count</span><br></blockquote><span></span><br><span></span><br><span>Ah, that totally explains what's happening here. Is there a PR?</span><br><span></span><br><blockquote type="cite"><span>2. for FE PGO, all loop trip count appears to be half of the real trip count.</span><br></blockquote><span></span><br><span></span><br><span>Wow, this was going to be next thing for me to investigate, thanks for the insights!</span></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">This is not true though. For FE PGO, the loop trip count is only halved for loops that are covered once. </div><div style="direction: inherit;"><br></div><div style="direction: inherit;">If a loop has good coverage, the trip count is barely adjusted. The adjustment has to do with confidence. </div><div style="direction: inherit;"><br></div><div style="direction: inherit;">I'm not sure "adding 1" is the best heuristic, but I'm fairly convinced that "adding 0" is worse. I believe Jakob linked to a source for his choice of +1 if you want to read up on it (look in the comments in CFE). </div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Separately from adjusting heuristics, perhaps loops with statically known trip counts should be given special treatment. Why rely on statistical heuristics if SCEV knows a loop counts to 10? IIRC, loops with no coverage are using a fixed heuristic (see BPI) for loop trip counts, something like "10x". We could have a pass that rewrote branch weights based on SCEV results instead (or use SCEV in BPI). </div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><span></span><br><span><a href="https://reviews.llvm.org/D24118">https://reviews.llvm.org/D24118</a></span><br><span></span><br><span></span><br><span></span><br></div></blockquote></body></html>