scala.tools.nsc.backend.icode.analysis.TypeFlowAnalysis
A type that does not depend on input to the transfer function.
A type for program points.
A type for program points.
A flow transfer function of a basic block.
The type found at a stack position.
The type of a given local variable.
.
Implements forward dataflow analysis: the transfer function is applied when inputs to a Program point change, to obtain the new output value.
Implements forward dataflow analysis: the transfer function is applied when inputs to a Program point change, to obtain the new output value.
the transfer function.
Initialize the in/out maps for the analysis of the given method.
Initialize the in/out maps for the analysis of the given method.
Abstract interpretation for one instruction.
Abstract interpretation for one instruction.
the number of times we iterated before reaching a fixpoint.
the number of times we iterated before reaching a fixpoint.
This method is invoked after one or more inlinings have been performed in basic blocks whose in-flow is non-bottom (this makes a difference later).
This method is invoked after one or more inlinings have been performed in basic blocks whose in-flow is non-bottom (this makes a difference later). What we know about those inlinings is given by:
staleOut: These are the blocks where a callsite was inlined.
For each callsite, all instructions in that block before the callsite were left in the block, and the rest moved to an afterBlock.
The out-flow of these basic blocks is thus in general stale, that's why we'll add them to the TFA worklist.inlined : These blocks were spliced into the method's CFG as part of inlining. Being new blocks, they haven't been visited yet by the typeflow analysis.staleIn : These blocks are what doInline() calls afterBlocks, ie the new home for instructions that previously appearead
after a callsite in a staleOut block. Based on the above information, we have to bring up-to-date the caches that forwardAnalysis and blockTransfer use to skip blocks and instructions.
Those caches are relevantBBs and isOnPerimeter (for blocks) and isOnWatchlist and lastInstruction (for CALL_METHODs).
Please notice that all inlined and staleIn blocks are reachable from staleOut blocks.
The update takes place in two steps:
(1) staleOut foreach { so => putOnRadar(linearizer linearizeAt (m, so)) }
This results in initial populations for relevantBBs and isOnWatchlist.
Because of the way isPreCandidate reuses previous decision-outcomes that are still valid,
this already prunes some candidates standing no chance of being inlined.
(2) populatePerimeter()
Based on the CFG-subgraph determined in (1) as reflected in relevantBBs,
this method detects some blocks whose typeflows aren't needed past a certain CALL_METHOD
(not needed because none of its successors is relevant for the purposes of inlining, see hasNoRelevantSuccs).
The blocks thus chosen are said to be "on the perimeter" of the CFG-subgraph.
For each of them, its lastInstruction (after which no more typeflows are needed) is found.
Reinitialize, but keep the old solutions.
Reinitialize, but keep the old solutions. Should be used when reanalyzing the same method, after some code transformation.
collect statistics?
collect statistics?
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'sremainingCALLs. 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,
remainingCALLstracks those callsites that still remain as candidates for inlining, so that Inliner can focus on those.remainingCALLsalso 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()inMTFAGrowablenow checks for inclusion of a basic block inrelevantBBsThe 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.