<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 1:47 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:36 PM, Xinliang David Li <<a href="mailto:xinliangli@gmail.com">xinliangli@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Mar 27, 2015 at 1:12 PM, Diego Novillo <<a href="mailto:dnovillo@google.com">dnovillo@google.com</a>> wrote:<br>
>><br>
>> On Fri, Mar 27, 2015 at 4:09 PM, Xinliang David Li <<a href="mailto:xinliangli@gmail.com">xinliangli@gmail.com</a>><br>
>> wrote:<br>
>> > How about only removing the scaling limit when PGO is on? I don't see<br>
>> > the<br>
>> > need for this change without PGO.<br>
>><br>
>> 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>
><br>
><br>
> What I mean is only do this when real profile data is used? I don't see the<br>
> patch has that check ?<br>
<br>
</span>Well, no. It's not really possible at the moment to determine whether<br>
the branch weights you get are coming from real profiles or not.<br>
<br>
It has no way of knowing and it would actually produce the same<br>
results. This patch works inside the frequency propagator. We could<br>
have a flag that tells the analysis about it, but there is no way of<br>
doing it automatically.<br></blockquote><div><br></div><div>We will be able to tell very soon once the MD_count is introduced to represent entry count.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
>><br>
>><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>
><br>
><br>
><br>
> This seems to show another weakness of the block frequency propagation --<br>
> it can not handle infinite loops.  We need to think about how to handle it<br>
> ..<br>
<br>
</span>It can, actually. On an infinite loop, the mass out of the loop is 0,<br>
the mass in the back edge is infinite.<br></blockquote><div><br></div><div>It can, but it will be utterly wrong with PGO.   No infinite loops will actually be infinite. It will end somewhere, somehow. The real profile data will capture the real count, but the propagated value will be so big (and so wrong) that it will make the 'profile' look really skewed.</div><div><br></div><div>David</div><div> </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>