TypeFlowAnalysis

Type Members

1. case class CallsiteInfo(bb: Global.icodes.BasicBlock, receiver: Global.Symbol, stackLength: Int, concreteMethod: Global.Symbol) extends Product with Serializable

   

2. class MTFAGrowable extends MethodTFA

   

   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
   • same check is performed before adding a block to the worklist, and as part of choosing successors. The bookkeeping supporting on-the-fly pruning of irrelevant blocks requires overridding most methods of the dataflow-analysis.

   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.

3. class MethodTFA extends DataFlowAnalysis[typeFlowLattice.type]

   

4. class Timer extends AnyRef

   

5. class VarBinding extends HashMap[Global.icodes.Local, Global.icodes.TypeKind]

   

   A map which returns the bottom type for unfound elements