scala.tools.nsc.backend.opt.Inliners
Classifies a pair (caller, callee) into one of four categories:
A transformation local to the body of the IMethod received as argument.
A transformation local to the body of the IMethod received as argument.
An linining decision consists in replacing a callsite with the body of the callee.
Please notice that, because analyzeMethod() itself may modify a method body,
the particular callee bodies that end up being inlined depend on the particular order in which methods are visited
(no topological sorting over the call-graph is attempted).
Making an inlining decision requires type-flow information for both caller and callee. Regarding the caller, such information is needed only for basic blocks containing inlining candidates (and their transitive predecessors). This observation leads to using a custom type-flow analysis (MTFAGrowable) that can be re-inited, i.e. that reuses lattice elements (type-flow information computed in a previous iteration) as starting point for faster convergence in a new iteration.
The mechanics of inlining are iterative for a given invocation of analyzeMethod(m),
and are affected by inlinings from previous iterations
(ie, "heuristic" rules are based on statistics tracked for that purpose):
(1) before the iterations proper start, so-called preinlining is performed.
Those callsites whose (receiver, concreteMethod) are both known statically
can be analyzed for inlining before computing a type-flow. Details in preInline()
(2) the first iteration computes type-flow information for basic blocks containing inlining candidates
(and their transitive predecessors), so called relevantBBs basic blocks.
The ensuing analysis of each candidate (performed by analyzeInc())
may result in a CFG isomorphic to that of the callee being inserted in place of the callsite
(i.e. a CALL_METHOD instruction is replaced with a single-entry single-exit CFG,
a substitution we call "successful inlining").
(3) following iterations have relevantBBs updated to focus on the inlined basic blocks and their successors only.
Details in MTFAGrowable.reinit()
Should method 'sym' being called in 'receiver' be loaded from disk?
Simple inliner.