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

[Easwaran Raman via llvm-commits]

To further add to David's replies, without something like this, it is
difficult to say whether a function 'foo' with an entry count of 1000
corresponds to a hot function or not: it is obviously hot if the max
function entry count itself is 1000 (then foo is the hottest function), but
perhaps not hot if the max function entry count is 1 million. The frontend
uses this value to set cold and inline-hint attributes, and the purpose of
this patch is to make this available to the optmizer.

I think we eventually want to use this (or max BB count) to find
per-callsite hotness and inline hot callsites, but perhaps an intermediate
step is to continue use the current heuristic of boosting hot callees, but
make that determination in the inliner instead of relying on attribute set
by the frontend.



On Fri, Nov 27, 2015 at 9:42 AM, Xinliang David Li <davidxl at google.com>
wrote:

>
>
> 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/20151202/ede446a3/attachment.html>