A full type-flow analysis on a method computes in- and out-flows for each basic block (that's what MethodTFA does).
A full type-flow analysis on a method computes in- and out-flows for each basic block (that's what MethodTFA does).
For the purposes of Inliner, doing so guarantees that an abstract typestack-slot is available by the time an inlining candidate (a CALL_METHOD instruction) is visited. This subclass (MTFAGrowable) of MethodTFA also aims at performing such analysis on CALL_METHOD instructions, with some differences:
(a) early screening is performed while the type-flow is being computed (in an override of blockTransfer
) by testing a subset of the conditions that Inliner checks later.
The reasoning here is: if the early check fails at some iteration, there's no chance a follow-up iteration (with a yet more lub-ed typestack-slot) will succeed.
Failure is sufficient to remove that particular CALL_METHOD from the typeflow's remainingCALLs
.
A forward note: in case inlining occurs at some basic block B, all blocks reachable from B get their CALL_METHOD instructions considered again as candidates
(because of the more precise types that -- perhaps -- can be computed).
(b) in case the early check does not fail, no conclusive decision can be made, thus the CALL_METHOD stays isOnwatchlist
.
In other words, remainingCALLs
tracks those callsites that still remain as candidates for inlining, so that Inliner can focus on those.
remainingCALLs
also caches info about the typestack just before the callsite, so as to spare computing them again at inlining time.
Besides caching, a further optimization involves skipping those basic blocks whose in-flow and out-flow isn't needed anyway (as explained next).
A basic block lacking a callsite in remainingCALLs
, when visisted by the standard algorithm, won't cause any inlining.
But as we know from the way type-flows are computed, computing the in- and out-flow for a basic block relies in general on those of other basic blocks.
In detail, we want to focus on that sub-graph of the CFG such that control flow may reach a remaining candidate callsite.
Those basic blocks not in that subgraph can be skipped altogether. That's why:
forwardAnalysis()
in MTFAGrowable
now checks for inclusion of a basic block in relevantBBs
The rest of the story takes place in Inliner, which does not visit all of the method's basic blocks but only on those represented in remainingCALLs
.
A map which returns the bottom type for unfound elements
The type flow lattice contains a binding from local variable names to types and a type stack.
The lattice of ICode types.
The lattice of type stacks.
The lattice of type stacks. It is a straight forward extension of the type lattice (lub is pairwise lub of the list elements).
A data-flow analysis on types, that works on
ICode
.