[PATCH] D98481: [Inliner] Do not inline mutual-recursive functions to avoid exponential size growth.

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 7 05:37:29 PST 2022


nikic added a comment.

I've been thinking about this some more, and I think something important to highlight is the interaction with simplification in the inliner pipeline: Normally, inlining inside an SCC stops either because the SCC has been split into trivial cycles (which are explicitly forbidden from further inlining) or because the functions in the SCC have increased in size to the point that no further inlining is possible. In both cases, the end result is that the SCC will not be inlined into a caller anymore. Now, due to simplication, it may be that in the second situation, we stop inlining because the functions become too large, but after simplication they are small enough for further inlining. Once we are in that situation, there is no longer anything blocking cross-SCC inlining, and we get the exponential inlining described here.

This makes me think that not inlining across (cyclic) SCCs is intended behavior of the bottom-up inliner, that currently breaks down when the inliner is combined with a simplification pipeline in the same CGSCC pass manager. This patch enforced this limitation in a more direct and robust way.

One could make an argument that we should be trying to inline again after functions inside an SCC have been simplified. This would then maximally inline within the SCC before considering the callers. But I suspect doing something like this would cause many other complications.

I found this example useful to consider, because it wasn't immediately obvious to me why we don't see issues in simpler cases: https://gist.github.com/nikic/5f389a8868483631861a6ec0931d968a


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98481



More information about the llvm-commits mailing list