[PATCH] D91567: [llvm][inliner] Reuse the inliner pass to implement 'always inliner'

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 16 19:35:09 PST 2020


dblaikie added a comment.

In D91567#2398461 <https://reviews.llvm.org/D91567#2398461>, @mtrofin wrote:

> In D91567#2398440 <https://reviews.llvm.org/D91567#2398440>, @dblaikie wrote:
>
>>> Performing the mandatory inlinings first simplifies the problem the full inliner needs to solve
>>
>> That confuses me a bit - is that suggesting that we don't run the AlwaysInliner when we are running the Inliner (ie: we only run the AlwaysInliner at -O0, and use the Inliner at higher optimization levels and let the Inliner do always inlining too)?
>> & sounds like this is suggesting that would change? That we would now perform always inlining separately from inlining? Maybe that's an orthogonal/separate change from one implementing the always inlining using the Inliner being run in a separate mode?
>
> In the NPM, we didn't run the AlwaysInliner until D86988 <https://reviews.llvm.org/D86988>. See also the discussion there. The normal inliner pass was, and still is, taking care of the mandatory inlinings if it finds them. Of course, if we completely upfronted those (which this patch can do), then the normal inliner wouldn't need to. I'm not suggesting changing that - meaning, it's straightforward for the normal inliner to take care of mandatory and policy-driven inlinings. The idea, though, is that if we upfront the mandatory inlinings, the shape of the call graph the inliner operates over is simpler and the effects of inlining probably more easy to glean by the decision making policy. There are trade-offs, though - we can increase that "ease of gleaning" by performing more function simplification passes between the mandatory inlinings and the full inliner.

OK, so if I understand correctly with the old Pass Manager there were two separate passes (always inliner and inliner - they share some code though, yeah?) and they were run in the pass pipeline but potentially (definitely?) not adjacent? New pass manager survived for quite a while with only one inlining pass, that included a mandatorily strong preference for inlining always-inline functions? But still missed some recursive cases. So D86988 <https://reviews.llvm.org/D86988> made the always inliner run right next to/before the inliner in the NPM.

Now there's tihs patch, to implement the AlwaysInliner using the inliner - but is also changing the order of passes to improve optimization opportunities by doing some cleanup after always inlining?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91567/new/

https://reviews.llvm.org/D91567



More information about the llvm-commits mailing list