Krzysztof Parzyszek
2013-Jun-14 17:56 UTC
[LLVMdev] RFC - Profile Guided Optimization in LLVM
On 6/12/2013 4:55 PM, Jakob Stoklund Olesen wrote:> > It seems like we might need a way of representing call graph profiling in addition to the existing branch probabilities? >Metadata on function definitions/declarations perhaps? I agree---the call graph profiling is of critical importance. I guess we should first see what types of data we already know may be useful and see how we would represent them within the compiler. Here's my list (in addition to the usual data gathered in such cases): * Function call frequency: - How many times a function has been called? * Function argument value profiling: - Is the function called with a small set of values for the parameters? - Is there any value that is particularly frequent for any of the arguments? - If the function takes pointers, are the pointers usually aligned? - If the function takes pointers, are they aliased? - etc. * Branch profiling: - Is the branch executed (i.e. taken/not-taken) in the same way as the last time, or does it often change direction? * Path profiling: - Correlation between branches, function calls, etc. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Jun 14, 2013, at 10:56 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:> > * Function argument value profiling: > - Is the function called with a small set of values for the parameters? > - Is there any value that is particularly frequent for any of the arguments? > - If the function takes pointers, are the pointers usually aligned? > - If the function takes pointers, are they aliased? > - etc.More generally it can be useful to collect value data for things like: - switch values, in order to split off one or more dominant values for an explicit check prior to a table look-up or binary-search through all the cases - function pointers, to make it possible to explicitly check against a very common pointer value so that the generated code can do a direct call to, or inline, the specific function (including virtual functions)> * Path profiling: > - Correlation between branches, function calls, etc.If interprocedural path profiling information is gathered, that should also be usable as a source for generating context-sensitive call graph profile data.
Yes. But I'd like to see us tackling these as part two of PGO push. The question is what designs we would have to decide on now to prevent re-design / re-implement later. Evan Sent from my iPad On Jun 14, 2013, at 12:10 PM, Mark Lacey <mark.lacey at apple.com> wrote:> > On Jun 14, 2013, at 10:56 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> * Function argument value profiling: >> - Is the function called with a small set of values for the parameters? >> - Is there any value that is particularly frequent for any of the arguments? >> - If the function takes pointers, are the pointers usually aligned? >> - If the function takes pointers, are they aliased? >> - etc. > > More generally it can be useful to collect value data for things like: > - switch values, in order to split off one or more dominant values for an explicit check prior to a table look-up or binary-search through all the cases > - function pointers, to make it possible to explicitly check against a very common pointer value so that the generated code can do a direct call to, or inline, the specific function (including virtual functions) > >> * Path profiling: >> - Correlation between branches, function calls, etc. > > If interprocedural path profiling information is gathered, that should also be usable as a source for generating context-sensitive call graph profile data. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev