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

[Duncan P. N. Exon Smith via llvm-commits]

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

Also, what's the point of supporting edge weights of 0 if they're
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?

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

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