[PATCH] D15489: Use getEdgeProbability() instead of getEdgeWeight() in BFI and remove getEdgeWeight() interfaces from MBPI.

[Xinliang David Li via llvm-commits]

In most of the cases, BFI can rebuild BB weights from probability (plus
entry count) correctly, but there are exceptions including 1) functions
with irreducible loops; and 2) lossy profile data in AutoFDO case.

For the example CFG, without Cong's patch, BFI can recover the BB2's weight
-- but this is not by design but based on the assumption that the weight of
backedge is not scaled (and still keep the original value of the sample
count). However since BFI will force BB2->BB3 to have have weight 1, the
iteration count of the loop will be 1000 which might be lower than actual.
With Cong's patch, the weight of BB2 recomputed can be way higher than
actual (as it is using probability 1's nominator value).

I think AutoFDO code needs to consider the limitation of BFI when
annotating loops -- basically if a loop has only single exit -- the exit
edge's weight can not be zero.

David

On Tue, Dec 15, 2015 at 10:22 AM, Dehao Chen via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> For the following CFG:
>
> BB1(weight:100)
> BB2(weight:1000)
> BB3(weight:100)
>
> BB1->BB2(probability: 0%)
> BB1->BB3(probability: 100%)
> BB2->BB2(probability: 100%)
> BB2->BB3(probability: 0%)
>
> Is there a way we can rebuild BB weights from probability?
> Dehao
>
> On Mon, Dec 14, 2015 at 9:58 PM, David Li <davidxl at google.com> wrote:
> > davidxl added a comment.
> >
> > Ok.  This is a case where loop exit edge is 'never' taken where the loop
> backedge is executed. With instrumentation based PGO, even without FE fix
> up of the 0 weight edge, such as scenario (aka, bad meta data) will never
> occur, so whatever output of BFI will be fine.
> >
> > However, with AutoFDO, such MD_prof data can actually be generated . For
> instance, the function has a single BB loop, and only the BB in the loop
> has some samples but the entry/exit BB has none.
> >
> > The BFI result before this patch will most likely under-estimate the
> loop trip count, while with this patch, it will most likely over-estimate
> it. I think neither results are ideal, and AutoFDO needs to do something
> (apply some heuristic) to prevent such case from being generated.  +dehao
> and +dnovillo for comments.
> >
> >
> > http://reviews.llvm.org/D15489
> >
> >
> >
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151215/bc6e5312/attachment.html>