<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 12, 2015 at 5:42 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank" class="cremed">dexonsmith@apple.com</a>></span> wrote:</div><div class="gmail_quote"><br><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">
There are two things going on here.<br>
<br>
Firstly, the loop scales are being capped at 4096.  I propagated this<br>
approximation from the previous version of BFI.  If it's causing a<br>
problem (which it looks like it is), we should drop it and fix what<br>
breaks.  You can play around with this by commenting out the `if`<br>
statement at the end of `computeLoopScale()` in<br>
BlockFrequencyInfoImpl.cpp.<br>
<br>
For example, without that logic this testcase gives:<br>
<span class=""><br>
    Printing analysis 'Block Frequency Analysis' for function 'main':<br>
    block-frequency-info: main<br>
     - entry: float = 1.0, int = 8<br>
</span>     - for.cond: float = 51.5, int = 411<br>
     - for.body: float = 50.5, int = 403<br>
     - for.cond1: float = 5051.0, int = 40407<br>
     - for.body3: float = 5000.5, int = 40003<br>
     - for.cond4: float = 505001.0, int = 4040007<br>
     - for.body6: float = 500000.5, int = 4000003<br>
     - for.inc: float = 500000.5, int = 4000003<br>
     - for.end: float = 5000.5, int = 40003<br>
     - for.inc7: float = 5000.5, int = 40003<br>
     - for.end9: float = 50.5, int = 403<br>
     - for.inc10: float = 50.5, int = 403<br>
<span class="">     - for.end12: float = 1.0, int = 8<br>
</span>     - for.cond13: float = 51.5, int = 411<br>
     - for.body15: float = 50.5, int = 403<br>
     - for.cond16: float = 500051.0, int = 4000407<br>
     - for.body18: float = 500000.5, int = 4000003<br>
     - for.inc19: float = 500000.5, int = 4000003<br>
     - for.end21: float = 50.5, int = 403<br>
     - for.inc22: float = 50.5, int = 403<br>
<span class="">     - for.end24: float = 1.0, int = 8<br>
</span>     - for.cond26: float = 500001.5, int = 4000011<br>
     - for.body28: float = 500000.5, int = 4000003<br>
     - for.inc29: float = 500000.5, int = 4000003<br>
<span class="">     - for.end31: float = 1.0, int = 8<br>
<br>
</span>(Now we get 500000.5 for all the inner loop bodies.)<br>
<br>
Secondly, instrumentation-based profiling intentionally fuzzes the<br>
profile data in the frontend using Laplace's Rule of Succession (look at<br>
`scaleBranchWeight()` in CodeGenPGO.cpp).<br>
<br>
For example, "loop 1" (which isn't affected by the 4096 cap) should give<br>
a loop scale of 500000.5, not 1000000.  (The profile data says<br>
1000000/10000 for the inner loop, 10000/100 for the middle, and 100/1<br>
for the outer loop.  Laplace says that we should fuzz these branch<br>
weights to 1000001/10001, 10001/101, and 101/2, which works out to<br>
1000001/2 == 500000.5 total.)<br>
<br></blockquote><div> </div></div>Thanks, Duncan. I've started working on this as a first step. Long term, the capping done during propagation is not much of a concern because we would probably not using propagation if real profile information is available (at least that's the initial thinking).<div><br></div><div>Thanks for all the feedback, folks. I'll start sending out patches soon that address specific issues. We can continue the discussion there.</div><div><br></div><div><br></div><div>Diego.</div></div></div>