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

Thu Aug 20 13:04:40 PDT 2015

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?

I still disagree with the use of Laplace's Rule of Succession in FE --
there are cases where profile data has high fidelity --- why can't
dead branches have 0 weight?

That of course belongs to a different discussion.

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

0 is a legit weight to be used in the interface. In some cases it can
be very useful. For instance it allows compiler to heavily optimize
for size for the 'dead' regions. Currently, only Clang FE with instr
PGO does not produce 0 weight, but presumably we can also introduce an
option such as -fprecise-profile for Clang so that zero weight can be
passed through.

The handling of zero weight in the implementation today, however, is
indeed very messy. Some converts 0 to 1 (BFI), some converts it to
some arbitrary value 16 (as the default weight), and some may also
treat it as real weight.  We do have a chance to clean those up when
the weight based CFG interfaces are migrated to BP based interfaces.

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

yes, I think those belong to a much larger clean up effort. This patch
serves as an interim preparation. It also makes some other pending
patches much cleaner.

thanks,

David

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