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

Cong Hou via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 11 15:48:31 PDT 2015


thanks,
Cong

On Tue, Aug 11, 2015 at 3:26 PM, Xinliang David Li <davidxl at google.com>
wrote:

> 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.
>

OK. So in this patch we can just turn zero weights into 1 in BPI, right? I
will update the patch accordingly.

Cong


>
> 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
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150811/2c5666ed/attachment.html>


More information about the llvm-commits mailing list