llvm dev - Mar 2015 - [LLVMdev] RFC - Improvements to PGO profile support

Example. Assuming the cap is 'C'

void bar()
{
    // ENTRY count is 4*C, after capping it becomes 'C'
    ...
}

void test()
{
  // BB1:   count(BB1) = C
  bar();

  // BB2:   count(BB2) = C
  bar();

}

void test2()
{
  // BB3:   count(BB3) = C
  bar();

  // BB4:   count(BB4) = C
  bar();
}

What would inliner see here ? When it sees callsite1 -- it might mistaken
that is the only dominating callsite to 'bar'.

David


On Tue, Mar 24, 2015 at 12:57 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
>
> On Tue, Mar 24, 2015 at 12:53 PM, Xinliang David Li <xinliangli at
gmail.com>
> wrote:
>
>> Capping also leads to other kinds of problems -- e.g., sum of incoming
>> edge count (callgraph) does not match the callee entry count etc.
>
>
> Can you explain these problems in more detail? I think that's essential
> for understanding why you think the design should be work in this way.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150324/079c7769/attachment.html>

On Tue, Mar 24, 2015 at 1:08 PM, Xinliang David Li <xinliangli at
gmail.com>
wrote:
> Example. Assuming the cap is 'C'
>
> void bar()
> {
>     // ENTRY count is 4*C, after capping it becomes 'C'
>     ...
> }
>
> void test()
> {
>   // BB1:   count(BB1) = C
>   bar();
>
>   // BB2:   count(BB2) = C
>   bar();
>
> }
>
> void test2()
> {
>   // BB3:   count(BB3) = C
>   bar();
>
>   // BB4:   count(BB4) = C
>   bar();
> }
>
> What would inliner see here ? When it sees callsite1 -- it might mistaken
> that is the only dominating callsite to 'bar'.
>
I don't understand, why would it assume this?

I was suggesting that each function would need to be associated with some
global weight, and the global weight ration between test and bar should
provide the needed information here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150324/bdfb253e/attachment.html>

On Tue, Mar 24, 2015 at 1:13 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
>
> On Tue, Mar 24, 2015 at 1:08 PM, Xinliang David Li <xinliangli at
gmail.com>
> wrote:
>
>> Example. Assuming the cap is 'C'
>>
>> void bar()
>> {
>>     // ENTRY count is 4*C, after capping it becomes 'C'
>>     ...
>> }
>>
>> void test()
>> {
>>   // BB1:   count(BB1) = C
>>   bar();
>>
>>   // BB2:   count(BB2) = C
>>   bar();
>>
>> }
>>
>> void test2()
>> {
>>   // BB3:   count(BB3) = C
>>   bar();
>>
>>   // BB4:   count(BB4) = C
>>   bar();
>> }
>>
>> What would inliner see here ? When it sees callsite1 -- it might
mistaken
>> that is the only dominating callsite to 'bar'.
>>
>
> I don't understand, why would it assume this?
>
because

count(ENTRY_bar) = SUM (count(callsite_i(bar)), for all i.

If the inliner sees the first callsite has the same count as the bar's
entry count, what assumption can it make (especially when the module has
only one callsite to be looked at)? With more callsites visible, it can
detect the insanity, but still it makes the data less useful.

>
> I was suggesting that each function would need to be associated with some
> global weight, and the global weight ration between test and bar should
> provide the needed information here?
>
See my previous reply. The data is there. We just need to preserve it.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150324/fc62e2f0/attachment.html>