[PATCH] D11915: Let edge weight be always greater than zero in both BPI and MBPI.

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 11 15:26:32 PDT 2015


On Tue, Aug 11, 2015 at 3:07 PM, Cong Hou <congh at google.com> wrote:
> congh added a comment.
>
> In http://reviews.llvm.org/D11915#222110, @davidxl wrote:
>
>> 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.
>
>
> 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.

True -- and that will be fixed in the future. The question is does
this regress from the current behavior? If not, take the simpler fix
for now.

David


>
>>
>
>>
>
>>  -------------------
>
>>
>
>> Current situation:
>
>>
>
>> 1. there is no client (other than opt) producing zero weight for BPI
>
>> 2. BPI can have missing weights (empty map entry) -- in which case, the edge weight returned is DEFAULT_WEIGHT= 16 for MBPI
>
>
> I think you mean MBB&MBPI as 3) & 6) below are for MBB.
>
>> 3. the default weight in the setter interface is '0' -- which can not be differentiated with real zero weight
>
>> 4. when Weight list for a BB is empty, the getter interface returns 16 as the default weight.
>
>
> Here MBB returns 0 but MBPI turns it into 16.
>
>> 5. the getter interface also unconditionally change 0 weight into DEFAULT_WEIGHT == 16
>
>> 6. the weight list and successor list can be out of sync.
>
>
>
> http://reviews.llvm.org/D11915
>
>
>


More information about the llvm-commits mailing list