llvm dev - Dec 2010 - [LLVMdev] Reviewer for our Path Profiling Implementation

[Cc'd to a bunch of people who have in the past expressed interest in
profiling with LLVM.]

On Mon, Dec 06, 2010 at 10:39:37 -0800, Bob Wilson
wrote:
> As far as I know, none of LLVM's standard passes make use of any
profiling
> information.  If we are going to get any value from having profiling
> support in LLVM, so that it is worth the effort of maintaining that code,
> we need to figure out how we're going to use it.
Right. That's a lot of grunt work, and no one person or group will probably
want to do it, especially if the results will not be very visible to others.

For this reason, our group in Vienna would like to propose a bundling of
various people's efforts in profiling. In particular, we would be willing to
host an LLVM branch that is open to profiling-related contributions such as:
- various kinds of profilers
- patches to preserve/update profiling information across existing passes
- code that improves existing passes based on profiling info
- code that communicates profiling data to the backend (to get MBB profile
  data, profile-based spill weights etc.)

The idea is to be more open to such submissions than mainline LLVM is, so
that we can experiment with and compare different approaches. Hopefully,
some parts of this would converge to a state that would then deemed
acceptable for mainline LLVM. Even if not, we would have a common codebase
in which the more boring parts (such as preserving info across simple
passes) are solved once and for all.
> In my opinion, it is essential that LLVM passes be able to query the
profile information with a standard API, and that they also be able to update
the profile information to account for changes to the code (e.g., when a block
is duplicated, when a loop is unrolled, etc.).  We need to have one API for
those things regardless of whether the profile information came from
__builtin_expect, simple heuristics, static analysis, or some kind of profile
feedback.
Absolutely. Bringing together people with different approaches to profiling
should hopefully help us get a good picture about what this standard API
could look like; and then also provide a number of profilers and clients
conforming to that API.

To get some idea about the number of people who could be involved in a
project like this, I would like to ask for a quick show of hands: Who would
be interested in contributing code to LLVM-with-profiling? (Either actual
profiling code, or passes that use profiling information.)
Who would want to use the branch, even without contributing?

-- 
Gergö Barany, research assistant                   gergo at
complang.tuwien.ac.at
Institute of Computer Languages        http://www.complang.tuwien.ac.at/gergo/
Vienna University of Technology                         Tel: +43-1-58801-58522
Argentinierstrasse 8/E185, 1040 Wien, Austria           Fax: +43-1-58801-18598

On Dec 21, 2010, at 7:27 AM, Gergö Barany wrote:
> [Cc'd to a bunch of people who have in the past expressed interest in
> profiling with LLVM.]
> 
> On Mon, Dec 06, 2010 at 10:39:37 -0800, Bob Wilson wrote:
>> As far as I know, none of LLVM's standard passes make use of any
profiling
>> information.  If we are going to get any value from having profiling
>> support in LLVM, so that it is worth the effort of maintaining that
code,
>> we need to figure out how we're going to use it.
> 
> Right. That's a lot of grunt work, and no one person or group will
probably
> want to do it, especially if the results will not be very visible to
others.
> 
> For this reason, our group in Vienna would like to propose a bundling of
> various people's efforts in profiling. In particular, we would be
willing to
> host an LLVM branch that is open to profiling-related contributions such
as:
> - various kinds of profilers
> - patches to preserve/update profiling information across existing passes
> - code that improves existing passes based on profiling info
> - code that communicates profiling data to the backend (to get MBB profile
>  data, profile-based spill weights etc.)
> 
> The idea is to be more open to such submissions than mainline LLVM is, so
> that we can experiment with and compare different approaches. Hopefully,
> some parts of this would converge to a state that would then deemed
> acceptable for mainline LLVM. Even if not, we would have a common codebase
> in which the more boring parts (such as preserving info across simple
> passes) are solved once and for all.
I would prefer to go the opposite direction: focus efforts on a single profiling
infrastructure in mainline LLVM.  You're not going to make much progress on
things like preserving profile info across passes that transform the CFG if you
have a branch that is even more open than mainline, which already has too many
separate profiling formats.  But, a branch may still be a good idea, and our
efforts may be complementary.  Things like the path profiling patches would fit
well on your proposed branch.
> 
>> In my opinion, it is essential that LLVM passes be able to query the
profile information with a standard API, and that they also be able to update
the profile information to account for changes to the code (e.g., when a block
is duplicated, when a loop is unrolled, etc.).  We need to have one API for
those things regardless of whether the profile information came from
__builtin_expect, simple heuristics, static analysis, or some kind of profile
feedback.
> 
> Absolutely. Bringing together people with different approaches to profiling
> should hopefully help us get a good picture about what this standard API
> could look like; and then also provide a number of profilers and clients
> conforming to that API.
I've got a proposal for what I'd like to do here.  I'll send it out
separately.
> 
> To get some idea about the number of people who could be involved in a
> project like this, I would like to ask for a quick show of hands: Who would
> be interested in contributing code to LLVM-with-profiling? (Either actual
> profiling code, or passes that use profiling information.)
> Who would want to use the branch, even without contributing?
I'd really prefer to work on trunk.

On Dec 21, 2010, at 7:57 AM, Bob Wilson wrote:
>> To get some idea about the number of people who could be involved in a
>> project like this, I would like to ask for a quick show of hands: Who
would
>> be interested in contributing code to LLVM-with-profiling? (Either
actual
>> profiling code, or passes that use profiling information.)
>> Who would want to use the branch, even without contributing?
> 
> I'd really prefer to work on trunk.
In the near term Adam's patch profiling should be checked into llvm/trunk. I
think it's important that it live on the same tree as the current llvm
profilers with which it's tightly integrated. As we work toward implementing
Bob's profiling proposal, it will either need to be integrated with the new
framework or it will be removed along with the other stale profilers. Even if
it's removed from trunk, the original implementation will still be available
in working condition from subversion. We should be able to maintain a reference
to it in the latest source or docs.

-Andy