[PATCH] D36726: [Inliner] Teach the inliner to propagate attributes that have specific effects on inlining thresholds when we happen to inline into the entry (extended) basic block.

[Chandler Carruth via llvm-commits]

On Mon, Aug 14, 2017 at 6:38 PM Xinliang David Li via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Mon, Aug 14, 2017 at 6:31 PM, Chandler Carruth via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> chandlerc added a comment.
>>
>> In https://reviews.llvm.org/D36726#841627, @davidxl wrote:
>>
>> > I will provide more comments on propagating the inline hint later.
>> However, I do think it is wrong to propagate the cold attribute in inliner
>> -- there should be already an inter-procedural attribute propagation pass
>> that does this.
>>
>>
>> While I'd love to teach our IPO attribute propagation to do that, we
>> might still need to do it here. The inliner might make the opportunity for
>> this propagation visible and then delete the call removing the chance to do
>> it all within a single pass run, and the interprocedural pass never get a
>> chance to see the intermediate state.
>>
>
>
> Not sure I understand this. Do you have an example showing that IPO prop
> won't work?
>

The inliner initially sees a direct call from A to B. The returned value is
a pointer which is in turn called. Neither A nor B are cold. Be returns the
address of a function C which is cold.

After inlining, A has a direct call to C (a cold function). The inliner can
iterate to this without any other pass running and inline C into A.

There is no longer a call edge to a cold function, we've lost the chance to
propagate anything. =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170815/a0940799/attachment.html>