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

[Cong Hou via llvm-commits]

On Tue, Dec 15, 2015 at 10:52 AM, Xinliang David Li via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

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

If we don't have 0 edge weight in AutoFDO and other weights are not very
high, then we should not get very large loop count even with this patch. I
think we have already transform all zero-weights into ones in AutoFDO,
right?

Cong


>
> 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
>>
>
>
> _______________________________________________
> 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/60f9cdf7/attachment.html>