[PATCH] D15003: Interface to attach maximum function count from PGO to module as module flags.

[Xinliang David Li via llvm-commits]

On Fri, Nov 27, 2015 at 5:13 AM, Diego Novillo <dnovillo at google.com> wrote:

>
>
> On Fri, Nov 27, 2015 at 12:44 AM, Xinliang David Li <davidxl at google.com>
> wrote:
>
>>
>>
>> On Thu, Nov 26, 2015 at 1:34 PM, Diego Novillo <dnovillo at google.com>
>> wrote:
>>
>>> dnovillo added a comment.
>>>
>>> How is this going to interact with SamplePGO?  Currently, I'm testing a
>>> change that adds the InlineHint attribute for functions that globally
>>> collected a fraction of samples greater than a given threshold.  Likewise,
>>> for functions that fall below another threshold, they receive the Cold
>>> attribute.
>>>
>>
>> Setting global max count and setting inlinehint are two different things
>> to do. The former helps per-callsite inline decision while the later is for
>> per-callee inline decision. Per-callee decision is not always good -- for
>> instance you don't want to inline a function just because it is hot -- the
>> callsite may be really cold.
>>
>
> Oh, agreed.  Setting inline hints is the only thing the profiler can do at
> this time, this is why I'm interested in a per-callsite solution.  I want
> to make sure that this change is taking us in that direction.  We will also
> need to undo the inline hint setting done in CodeGenPGO.cpp.
>
>

right -- you really don't need inlinehint -- which should only be needed to
pass user's hint. By using entry count and max count passed, the inliner
can get the same information. More importantly, inliner will also update
the entry count of the out of line instance as inlining is happening, so it
will always see the most up to date info. For instance, after the most
dominating callsite is inlined, the callee may become super cold, and this
will be reflected during inline update.



>
>>
>>>
>>> The API talks in terms of function counts, how is this related to the
>>> entry count I added earlier? What would SamplePGO have to do here?
>>>
>>>
>> The inline decision is based on the new information provided by the API
>> and the entry count info -- from the entry count and block relative
>> frequency, the inliner can find out the profile count of the callsite --
>> the callsite count is then compared with a threshold determined by the
>> global hotness information provided by the API.
>>
>
> So, the units do not matter.  This is just a number.  Higher values mean
> hotter functions.  Easwaran, could you add documentation to this effect?
> Thanks.
>

Right -- the requirement is that the entry count should be in same unit as
this.


>
> This API only sets the max entry count for the function.  How do we set
> the per-callsite counts?  SamplePGO has this information now but does not
> know what to do with it.
>

To be precise, it  sets the count of the hottest function entry in whole
program. This API allows the compiler to migrate the inline hint logic
currently done in FE to inliner (so that inline hint does not need to be
passed as you mentioned).  This is the first step.   As I mentioned, we
also need max BB count of the program for inliner to decide per-callsite
hotness. That can either be done in a follow up or together in this patch.


David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151127/13204522/attachment.html>