[PATCH] D11442: Provide an interface normalizeSuccWeights in MachineBasicBlock to normalize its successors' weights and use it in other places.

[Cong Hou via llvm-commits]

On Tue, Aug 18, 2015 at 5:58 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > On 2015-Aug-18, at 11:47, Cong Hou <congh at google.com> wrote:
> >
> > Hi Duncan
> >
> > Could you please take a look at this patch again? I updated this patch
> by converting all zero weights into ones in BFI. You can check my previous
> message below for more details.
> >
> > Thank you very much!
> >
>
>
> > Index: test/Transforms/SampleProfile/branch.ll
> > ===================================================================
> > --- test/Transforms/SampleProfile/branch.ll
> > +++ test/Transforms/SampleProfile/branch.ll
> > @@ -36,18 +36,18 @@
> >    tail call void @llvm.dbg.value(metadata i8** %argv, i64 0, metadata
> !14, metadata !DIExpression()), !dbg !27
> >    %cmp = icmp slt i32 %argc, 2, !dbg !28
> >    br i1 %cmp, label %return, label %if.end, !dbg !28
> > -; CHECK: edge entry -> return probability is 0 / 1 = 0%
> > -; CHECK: edge entry -> if.end probability is 1 / 1 = 100%
> > +; CHECK: edge entry -> return probability is 1 / 2 = 50%
> > +; CHECK: edge entry -> if.end probability is 1 / 2 = 50%
>
> This doesn't look like the right result to me.
>
> In the frontend instrumentation, we used Laplace's Rule of Succession
> when creating branch weights.  Should you do the same thing with the
> sampling profile?  Or something similar?
>

You mean converting 0 and 1 into 1 and 2? I am not sure if it is reasonable
to do this for branch weights that are indicated in .ll files: clients may
not be aware of this change and they may use 0 and 1 weights intentionally
to represent a very cold branch and a very hot branch. The change in this
patch is quite temporary and it is borrowed from BFI (explained below).


>
> Also, what's the point of supporting edge weights of 0 if they're
> ignored in branch probability?
>

Sorry, I don't get it here. Where zero edge weights are supported? And how
they are ignored in branch probability?


>
> More below...
>
> > thanks,
> > Cong
> >
> > On Tue, Aug 11, 2015 at 4:59 PM, Cong Hou <congh at google.com> wrote:
> > Hi Duncan
> >
> > I committed this patch in the past after your approval, but it broke
> some others tests (see PR24377) that are not in the tree and I then
> reverted it. Later I investigated the bug and found the problem is that we
> could get zero edge weights from BPI (usually the zero weight is from test
> cases). When those zero weights come to MBPI, they will be turned into 16,
> which will lead to overflow when summing up weights. For example, if we
> have two edge weights 0 and UINT32_MAX, in the weight normalization
> function they are OK as the sum of them is not greater than UINT32_MAX. But
> when summing them up in MBPI we are adding 16 + UINT32_MAX instead of 0 +
> UINT32_MAX. This will lead to assertion failures.
>
> Is this a problem in MBPI that should be fixed?  Maybe we should
> have another mechanism for specifying "unknown"?  Or maybe we
> should deal gracefully with 0 weights?
>

I am considering to propose an improvement on MBB::addSuccessor().
Specifically, we can discard the use of default parameter but split it into
two interfaces: the one without the weight parameter will use default
weight, and the one with the weight parameter will accept any weight passed
in, including 0. In this way, we can still allow zero weights indicated by
clients without converting it into default weight later (then MBPI won't
convert zero into default weight anymore). What do you think?


>
> > As when BFI meets zero weights it will turn them into ones,
>
> I thought BFI only did this when it was normalizing.  Am I wrong?
>

In BlockFrequencyInfoImplBase::addToDist(), the first statement is:

  if (!Weight)
    Weight = 1;

This is where BFI turns zero weights into ones. That is why I did the same
thing in this patch. Another way to normalize zero weights is to let other
weights very big and turn zero into one. For example, we can normalize 0
and 1 into 1 and UINT32_MAX - 1. But I am not sure this is the right way.



>
> > I did the same trick in BPI by turning zero edge weights into ones. Now
> those test failures have disappeared.
> >
> > Could you please take a look again at this patch? The additional update
> is in lib/Analysis/BranchProbabilityInfo.cpp and some test cases. Thank you
> very much!
> >
> >
> > thanks,
> > Cong
> >
> > On Tue, Aug 11, 2015 at 4:43 PM, Cong Hou <congh at google.com> wrote:
> > congh removed rL LLVM as the repository for this revision.
> > congh updated this revision to Diff 31882.
> > congh added a comment.
> >
> > Update the patch by turning zero edge weights into one in BPI so that we
> won't get zero weights in BPI anymore.
> >
> >
> > http://reviews.llvm.org/D11442
> >
> > Files:
> >   include/llvm/CodeGen/MachineBasicBlock.h
> >   include/llvm/CodeGen/MachineBranchProbabilityInfo.h
> >   lib/Analysis/BranchProbabilityInfo.cpp
> >   lib/CodeGen/IfConversion.cpp
> >   lib/CodeGen/MachineBasicBlock.cpp
> >   lib/CodeGen/MachineBlockPlacement.cpp
> >   lib/CodeGen/MachineBranchProbabilityInfo.cpp
> >   test/CodeGen/X86/pr24377.ll
> >   test/Transforms/SampleProfile/branch.ll
> >   test/Transforms/SampleProfile/calls.ll
> >   test/Transforms/SampleProfile/propagate.ll
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150819/3e2ad706/attachment.html>