Dataflow analysis Discovering Global Live Ranges of Variables - PowerPoint PPT Presentation

Dataflow analysis Discovering Global Live Ranges of Variables cs4713 1

Optimization and analysis Requirement for optimizations  Correctness (safety)   must preserve the meaning of the input computation Profitability   must improve code quality Program analysis  Statically examines input computation to ensure safety and  profitability of optimizations Compile-time reasoning of runtime program behavior   Undecidable in general due to external program input, complex control flow, and pointer/array references  Conservative approximation of program runtime behavior: may miss opportunities of applying optimization, but ensure all optimizations are correct Data-flow analysis  Reason about flow of values on control-flow graphs  Example: available expression analysis for global redundancy  elimination Can be used for program optimization or program understanding  cs4713 2

Control-flow graph  Graphical representation of runtime control-flow paths  Nodes of graph: basic blocks (straight-line computations)  Edges of graph: flows of control  Useful for collecting information about computation  Detect loops, remove redundant computations, register allocation, instruction scheduling…  Alternative CFG: Each node contains a single statement i =0; …… i = 0 if I < 50 while (i < 50) { t1 = b * 2; a = a + t1; t1 := b * 2; i = i + 1; …… a := a + t1; } i = i + 1; …. cs4713 3

Live variable analysis  A data-flow analysis problem  A variable v is live at CFG point p iff there is a path from p to a use of v along which v is not redefined  At any CFG point p, what variables are alive?  Live variable analysis can be used in  Global register allocation  Dead variables no longer need to be in registers  Useless-store elimination  Dead variable don’t need to be stored back to memory  Uninitialized variable detection  No variable should be alive at program entry point cs4713 4

Computing live variables  For each basic block n, let  UEVar(n)=variables used before any definition in n  VarKill(n)=variables defined (modified) in n (killed by n) for each basic block n:S1;S2;S3;…;Sk VarKill := ∅ M UEVar(n) := ∅ for i = 1 to k S1: m := y * z suppose Si is “x := y op z” S2: y := y -z if y ∉ VarKill S3: o := y * z UEVar(n) = UEVar(n) ∪ {y} if z ∉ VarKill UEVar(n) = UEVar(n) ∪ {z} VarKill = VarKill ∪ {x} cs4713 5

Computing live variables  For each basic block n, m:=a+b A let n:=a+b B  UEVar(n) q:=a+b vars used before defined p:=c+d C r:=c+d  VarKill(n) r:=c+d vars defined (killed by n) Goal: evaluate vars e:=b+18 e:=a+17 alive on exit from n D s:=a+b E t:=c+d u:=e+f u:=e+f LiveOut(n)= ∪ m ∈ succ(n) (UEVar(m) ∪ v:=a+b (LiveOut(m) - VarKill(m)) F w:=c+d X:=e+f y:=a+b G z:=c+d cs4713 6

Algorithm: computing live variables  For each basic block n, let UEVar(n)=variables used before any definition in n  VarKill(n)=variables defined (modified) in n (killed by n)  Goal: evaluate names of variables alive on exit from n LiveOut(n)= ∪ (UEVar(m) ∪ (LiveOut(m) - VarKill(m))  m ∈ succ(n) for each basic block bi compute UEVar(bi) and VarKill(bi) LiveOut(bi) := ∅ for (changed := true; changed; ) changed = false for each basic block bi old = LiveOut(bi) LiveOut(bi)= ∪ (UEVar(m) ∪ (LiveOut(m) - VarKill(m)) m ∈ succ(bi) if (LiveOut(bi) != old) changed := true cs4713 7

Iterative dataflow algorithm  Iterative evaluation of result for each basic block bi sets until a fixed point is compute Gen(bi) and Kill(bi) reached Result(bi) := ∅  Does the algorithm always for (changed := true; changed; ) terminate? changed = false  If the result sets are bounded and grow for each basic block bi monotonically, then yes; old = Result(bi) Otherwise, no. Result(bi)=  Fixed-point solution is independent of evaluation ∩ or ∪ order [m ∈ pred(bi) or succ(bi)]  What answer does the (Gen(m) ∪ (Result(m)-Kill(m)) algorithm compute? if (Result(bi) != old)  Unique fixed-point solution changed := true  The meet-over-all-paths solution  How long does it take the algorithm to terminate?  Depends on traversing order of basic blocks cs4713 8

Traversing order of basic blocks  Facilitate fast convergence to the fixed point 4  Postorder traversal postorder 2 3  Visits as many of a nodes successors as possible before visiting the node 1  Used in backward data-flow analysis  Reverse postorder traversal  Visits as many of a node’s predecessors as possible 1 before visiting the node  Used in forward data-flow 3 2 Reverse analysis postorder 4 cs4713 9

More about dataflow analysis  Sources of imprecision  Unreachable control flow edges, array and pointer references, precedure calls  Other data-flow programs  Reaching definition analysis  A definition point d of variable v reaches CFG point p iff there is a path from d to p along which v is not redefined  At any CFG point p, what definition points can reach p?  Very busy expression analysis  An expression e is very busy at a CFG point p if it is evaluated on every path leaving p, and evaluating e at p yields the same result.  At any CFG point p, what expressions are very busy?  Constant propagation analysis  A variable-value pair (v,c) is valid at a CFG point p if on every path from procedure entry to p, variable v has value c  At any CFG point p, what variables have constants? cs4713 10