[LLVMdev] RFC - Improvements to PGO profile support

Diego Novillo dnovillo at google.com
Tue Feb 24 15:31:29 PST 2015


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/20150224/f2b0ec58/attachment.html>


More information about the llvm-dev mailing list