[LLVMdev] Reviewer for our Path Profiling Implementation
Bob Wilson
bob.wilson at apple.com
Mon Dec 6 10:39:37 PST 2010
On Dec 3, 2010, at 11:21 AM, Adam Preuss wrote:
> I am a student at the University of Alberta under the
> supervision of José Nelson Amaral, and I have been working on
> implementing path profiling into LLVM. I have completed my project
> and would like to submit it.
>
> We are looking for a reviewer for the path profiling implementation. We
> have sent previous requests to the llvmdev list but have so far been
> unsuccessful.
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.
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.
The existing support for profile information does not include such an API, which is at least part of the reason why nothing uses it. Adding path profiling would only make things worse in that it would be yet another format of profiling information. Do you have any thoughts on how to provide an API for LLVM to use and manipulate the path profiling information, in ways that would also apply to other kinds of profile info?
I have not reviewed your patch in detail, but as you can tell, I have some concerns about whether it makes sense to include this in LLVM. I've never worked on a compiler with path profiling, and the kind of profiling APIs that I can think of would not work very well with path profiling. I don't think it makes sense to include this as a standard part of LLVM unless we can come up with a way to make it useful. If you have suggestions on how to do that, it would help.
More information about the llvm-dev
mailing list