<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 1:12 PM, Diego Novillo <span dir="ltr"><<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Mar 27, 2015 at 4:09 PM, Xinliang David Li <<a href="mailto:xinliangli@gmail.com">xinliangli@gmail.com</a>> wrote:<br>
> How about only removing the scaling limit when PGO is on? I don't see the<br>
> need for this change without PGO.<br>
<br>
</span>This is what my patch does, and it's getting into issues.  With the<br>
scaling limit gone, the frequencies propagated overflow 64bits, so<br>
they need to be scaled down to a 64bit space.<br></blockquote><div><br></div><div>What I mean is only do this when real profile data is used? I don't see the patch has that check ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To be on the safe side, my patch is mapping them down to a 32bit<br>
space, but I am squishing them too much on  the lower end. So regions<br>
of the CFG that before had distinct temperatures are now showing up<br>
with frequency == 1.<br>
<br>
I need a better smoother for the mapping from the Scale64 floats down<br>
to 64bit (or 32bit) integers.<br></blockquote><div><br></div><div><br></div><div>This seems to show another weakness of the block frequency propagation --  it can not handle infinite loops.  We need to think about how to handle it ..</div><div><br></div><div>David</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
<br>
Diego.<br>
</font></span></blockquote></div><br></div></div>