[LLVMdev] RFC - Improvements to PGO profile support

[Justin Bogner]

Diego Novillo <dnovillo at google.com> writes:
> David Li and I are preparing a document where we describe the major issues
> that we'd like to address. The document is a bit on the lengthy side, so it
> may be easier to start with an email discussion. This is a summary of the main
> changes we are looking at:
>
>  1. Need to faithfully represent the execution count taken from dynamic
>     profiles. Currently, MD_prof does not really represent an execution count.
>     This makes things like comparing hotness across functions hard or
>     impossible. We need a concept of global hotness.
>  2. When the CFG or callgraph change, there need to exist an API for
>     incrementally updating/scaling counts. For instance, when a function is
>     inlined or partially inlined, when the CFG is modified, etc. These counts
>     need to be updated incrementally (or perhaps re-computed as a first step
>     into that direction).
>  3. The inliner (and other optimizations) needs to use profile information and
>     update it accordingly. This is predicated on Chandler's work on the pass
>     manager, of course.
>     Need to represent global profile summary data. For example, for global
>     hotness determination, it is useful to compute additional global summary
>     info, such as a histogram of counts that can be used to determine hotness
>     and working set size estimates for a large percentage of the profiled
>     execution.

Great! Looking forward to hearing more.

> My main question at the moment is what would be the best way of addressing
> them. Some seem to require new concepts to be implemented (e.g., execution
> counts). Others could be addressed as simple bugs to be fixed in the current
> framework.
>
> Would it make sense to present everything in a unified document and discuss
> that? I've got some reservations about that approach because we will end up
> discussing everything at once and it may not lead to concrete progress.
> Another approach would be to present each issue individually either as patches
> or RFCs or bugs.

While a unified document is likely to lead to a an unfocused discussion,
talking about the problems piecemeal will make it harder to think about
the big picture. I suspect that an overview of the issues and some brief
notes on how you're thinking of approaching each will be useful. We can
break out separate discussions from there on any points that are
contentious or otherwise need to be discussed in further detail.