[PATCH] D61540: [PGO] Use sum of count values to fix func entry count and add a check to verify BFI counts

Rong Xu via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 19 17:15:44 PST 2020


On Thu, Nov 19, 2020 at 4:24 PM David Li via Phabricator <
reviews at reviews.llvm.org> wrote:

> davidxl added inline comments.
>
>
> ================
> Comment at: llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:1657
> +  uint64_t FuncEntryCount = Func.getBBInfo(&*F.begin()).CountValue;
> +  uint64_t NewEntryCount = 0.5 + FuncEntryCount * Scale;
> +  if (NewEntryCount == 0)
> ----------------
> xur wrote:
> > davidxl wrote:
> > > Perhaps take the max of the original func entry count and the new
> entry count?
> > Not sure if want a max here. Here a value of 1 makes the sum of raw
> counters and sum of BFI counters close to each other, better than original
> func entry count.
> >
> > Using max will never reduce the entry count -- I don't think that is
> what we want.
> I thought the intention of the patch is to correct the 'guessed' entry
> count which is usually '1'. If the original entry count is not 1, it is
> usually a value we can trust. Sometimes BFI can create insanely large
> counts which makes the scale really small. It ends up leading to new entry
> entry count to become 1 (from non-1 value). Is that the intended behavior?
>
> No. that was not the intention. I had this patch for a long time. There
are other factors that make BFI counters deviate from raw profile values.
Those facts include bugs in BFI, round-off error, inconsistent profile. I
have seen all of them.

>
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D61540/new/
>
> https://reviews.llvm.org/D61540
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201119/49d54789/attachment.html>


More information about the llvm-commits mailing list