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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
