llvm dev - Mar 2015 - [LLVMdev] RFC - Improvements to PGO profile support

Folks,

I've created a few bugzilla issues with details of some of the things
I'll
be looking into. I'm not yet done wordsmithing the overall design document.
I'll try to finish it by early next week at the latest.

In the meantime, these are the specific bugzilla issues I've opened:

22716 <http://llvm.org/bugs/show_bug.cgi?id=22716>librarieGlobal A
dnovillo at google.comNEW---Need a mechanism to represent global profile
counts in CFG and MachineCFG <http://llvm.org/bugs/show_bug.cgi?id=22716>
16:47:0122718 <http://llvm.org/bugs/show_bug.cgi?id=22718>librarieGlobal A
dnovillo at google.comNEW---Information loss and performance issues in branch
probability representation <http://llvm.org/bugs/show_bug.cgi?id=22718>
17:37:3922719 <http://llvm.org/bugs/show_bug.cgi?id=22719>librarieGlobal A
dnovillo at google.comNEW---Improvements in raw branch profile data
representation <http://llvm.org/bugs/show_bug.cgi?id=22719>17:48:34

I'm hoping the descriptions in the bugs make sense on their own. If not,
please use the bugs to beat me with a clue stick and I'll clarify.


Thanks.  Diego.


On Tue, Feb 24, 2015 at 6:31 PM, Diego Novillo <dnovillo at google.com>
wrote:
>
> We (Google) have started to look more closely at the profiling
> infrastructure in LLVM. Internally, we have a large dependency on PGO to
> get peak performance in generated code.
>
> Some of the dependencies we have on profiling are still not present in
> LLVM (e.g., the inliner) but we will still need to incorporate changes to
> support our work on these optimizations. Some of the changes may be
> addressed as individual bug fixes on the existing profiling infrastructure.
> Other changes  may be better implemented as either new extensions or as
> replacements of existing code.
>
> I think we will try to minimize infrastructure replacement at least in the
> short/medium term. After all, it doesn't make too much sense to replace
> infrastructure that is broken for code that doesn't exist yet.
>
> 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.
>
> There are other changes that we will need to incorporate. David, Teresa,
> Chandler, please add anything large that I missed.
>
> 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.
>
> I will be taking on the implementation of several of these issues. Some of
> them involve the SamplePGO harness that I added last year. I would also
> like to know what other bugs or problems people have in mind that I could
> also roll into this work.
>
>
> Thanks. Diego.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150226/c7d4d2ab/attachment.html>

> On Mar 2, 2015, at 4:19 PM, Diego Novillo <dnovillo at google.com>
wrote:
> 
> On Thu, Feb 26, 2015 at 6:54 PM, Diego Novillo <dnovillo at google.com
<mailto:dnovillo at google.com>> wrote:
> 
> I've created a few bugzilla issues with details of some of the things
I'll be looking into. I'm not yet done wordsmithing the overall design
document. I'll try to finish it by early next week at the latest.
> 
> The document is available at
> 
>
https://docs.google.com/document/d/15VNiD-TmHqqao_8P-ArIsWj1KdtU-ElLFaYPmZdrDMI/edit?usp=sharing 
<https://docs.google.com/document/d/15VNiD-TmHqqao_8P-ArIsWj1KdtU-ElLFaYPmZdrDMI/edit?usp=sharing>
> 
> There are several topics covered. Ideally, I would prefer that we discuss
each topic separately. The main ones I will start working on are the ones
described in the bugzilla links we have in the doc.
> 
> This is just a starting point for us. I am not at all concerned with
implementing exactly what is proposed in the document. In fact, if we can get
the same value using the existing support, all the better.
> 
> OTOH, any other ideas that folks may have that work better than this are
more than welcome. I don't have really strong opinions on the matter. I am
fine with whatever works.
Thanks for the detailed write-up on this. Some of the issues definitely need to
be addressed. I am concerned, though, that some of the ideas may be leading
toward a scenario where we have essentially two completely different ways of
representing profile information in LLVM IR. It is great to have two
complementary approaches to collecting profile data, but two representations in
the IR would not make sense.

The first issue raised is that profile execution counts are not represented in
the IR. This was a very intentional decision. I know it goes against what other
compilers have done in the past. It took me a while to get used to the idea when
Andy first suggested it, so I know it seems awkward at first. The advantage is
that branch probabilities are much easier to keep updated in the face of
compiler transformations, compared to execution counts. We are definitely
missing the per-function execution counts that are needed to be able to compare
relative “hotness” across functions, and I think that would be a good place to
start making improvements. In the long term, we should keep our options open to
making major changes, but before we go there, we should try to make incremental
improvements to fix the existing infrastructure.

Many of the other issues you raise seem like they could also be addressed
without major changes to the existing infrastructure. Let’s try to fix those
first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150305/8b67ebd8/attachment.html>