[PATCH] D11442: Provide an interface normalizeSuccWeights in MachineBasicBlock to normalize its successors' weights and use it in other places.
Cong Hou via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 20 14:56:31 PDT 2015
congh added inline comments.
================
Comment at: test/Transforms/SampleProfile/branch.ll:41
@@ -41,2 +40,3 @@
+; CHECK: edge entry -> if.end probability is 1 / 2 = 50%
if.end: ; preds = %entry
----------------
davidxl wrote:
> Since BFI always ignores zero weight which leads to inconsistency (as BPI did not ignore zero weight before this fix, only BFI does it).
>
> If the test case really intend to test a highly biased branch here, I think the test case should be modified to not use zero weight after this fix (as it now will be completely ignored). Changing the the results to 50% may violate what is intended by the test.
I did an investigation on this. The weight 0 and 1 are not indicated in this test cased but are read from a sample profile file, in which most lines have zero weights except two which are large weights. Where does 1 come from? When a zero weight is read from sample profile, it is converted to 1 (see include/llvm/ProfileData/SampleProf.h:175). In the comment, it says that the weight is set to 0 if the profile data is missing. If the profile data exist and the number of samples is zero, it will be converted to 1 to differentiate those two different cases. However, this will lead to a possible result that two edges from the same block have weight 0 and 1 (0 for missing profile and 1 for 0 sample): now how to interpret them? I think here it is a good idea to convert 0 to 1 in BPI for this case. For the original test case the probability 0 and 100% are quite wrong, but 50% and 50% as in the updated test case is more reasonable.
http://reviews.llvm.org/D11442
More information about the llvm-commits
mailing list