<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">thanks,<br>Cong</div></div>
<br><div class="gmail_quote">On Tue, Aug 11, 2015 at 3:26 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@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 Tue, Aug 11, 2015 at 3:07 PM, Cong Hou <<a href="mailto:congh@google.com">congh@google.com</a>> wrote:<br>
> congh added a comment.<br>
><br>
> In <a href="http://reviews.llvm.org/D11915#222110" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11915#222110</a>, @davidxl wrote:<br>
><br>
>> Ok -- it is a very messy situation that need lots of cleanup (summarized below).  For now, since the only producer of zero weight for BPI is from 'opt' by reading developer's hand writing .ll file, I suggest simply set zero weight to 1 in calcMetaDataWeights to match BlockFrequencyInfoImpl's behavior.<br>
><br>
><br>
> Assume the user uses weights 0 and 1 to represent that one edge is very very cold and another one is very very hot, then this modification makes them to 1 and 1, which has the totally different meaning.<br>
<br>
</span>True -- and that will be fixed in the future. The question is does<br>
this regress from the current behavior? If not, take the simpler fix<br>
for now.<br></blockquote><div><br></div><div>OK. So in this patch we can just turn zero weights into 1 in BPI, right? I will update the patch accordingly.</div><div><br></div><div>Cong</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>
David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
>><br>
><br>
>><br>
><br>
>>  -------------------<br>
><br>
>><br>
><br>
>> Current situation:<br>
><br>
>><br>
><br>
>> 1. there is no client (other than opt) producing zero weight for BPI<br>
><br>
>> 2. BPI can have missing weights (empty map entry) -- in which case, the edge weight returned is DEFAULT_WEIGHT= 16 for MBPI<br>
><br>
><br>
> I think you mean MBB&MBPI as 3) & 6) below are for MBB.<br>
><br>
>> 3. the default weight in the setter interface is '0' -- which can not be differentiated with real zero weight<br>
><br>
>> 4. when Weight list for a BB is empty, the getter interface returns 16 as the default weight.<br>
><br>
><br>
> Here MBB returns 0 but MBPI turns it into 16.<br>
><br>
>> 5. the getter interface also unconditionally change 0 weight into DEFAULT_WEIGHT == 16<br>
><br>
>> 6. the weight list and successor list can be out of sync.<br>
><br>
><br>
><br>
> <a href="http://reviews.llvm.org/D11915" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11915</a><br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>