[LLVMdev] Reviewer for our Path Profiling Implementation

[Bob Wilson]

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.