Download Program Analysis and Understanding - Fall 2004 | CMSC 631 and more Assignments Computer Science in PDF only on Docsity!
Static Single Assignment Form and Dominators CMSC 631 – Program Analysis and Understanding Fall 2004 CMSC 631, Fall 2004 2
• Data flow analysis needs to represent facts at
every program point
• What if
■ (^) There are a lot of facts and ■ (^) There are a lot of program points? ■ potentially takes a lot of space/time
• Most likely, we’re keeping track of irrelevant facts
Motivation
CMSC 631, Fall 2004 3
Example
x := 3 y := a + b z := 2 * y w := y + z a > b y := a - b y := y * 10 w := w + y z := w + x CMSC 631, Fall 2004 4
• Instead, we’d like to use a sparse representation
■ (^) Only propagate facts about x where they’re needed
• Enter static single assignment form
■ (^) Each variable is defined (assigned to) exactly once ■ But may be used multiple times
Sparse Representation
• Add SSA edges from definitions to uses
■ (^) No intervening statements use/define variable ■ (^) Safe to propagate only along SSA edges
Example: SSA
x 1 := 3 y 1 := a 1 + b 1 z 1 := 2 * y 1 w 2 := y 1 + z 1 a 1 > b 1 y 2 := a 1 - b 1 y 3 := y 2 * 10 w 3 := w 1 + y 3 z 1 := w? + x 1
• Add Φ functions/nodes to model joins
■ (^) Intuitively, takes meet of arguments ■ (^) At code generation time, need to eliminate Φ nodes
What About Joins?
x 1 := 3 y 1 := a 1 + b 1 z 1 := 2 * y 1 w 2 := y 1 + z 1 a 1 > b 1 y 2 := a 1 - b 1 y 3 := y 2 * 10 w 3 := w 1 + y 3 w 4 := !(w 2 , w 3 ) z 1 := w 4 + x 1
CMSC 631, Fall 2004 7
• Initialize facts at each program point
■ C(n) := top
• Add all SSA edges to the worklist
• While the worklist isn’t empty,
■ (^) Remove an edge (x, y) from the worklist ■ (^) C(y) := C(y) meet C(x) ■ Add SSA edges from y if C(y) changed
Constant Propagation Revisited
CMSC 631, Fall 2004 8
• Alternative: Don’t do renaming; instead,
compute simple def-use chains (reaching
definitions)
■ (^) Propagate facts along def-use chains
• Drawback: Potentially quadratic size
Def-Use Chains vs. SSA
CMSC 631, Fall 2004 9
Def-Use Chains vs. SSA (cont’d)
a := 1 a := 2 a := 3 b := a c := a d := a Def-Use Chains a 1 := 1 a 2 := 2 a 3 := 3 b 1 := a 4 c 1 := a 4 d 1 := a 4 a 4 := !(a 1 , a 2 , a 3 ) SSA Form
Quadratic vs. (in practice) linear behavior
CMSC 631, Fall 2004 10
• So far, we assume that all branches can be taken
■ (^) But what if some branches are never taken in practice?
- Debugging code that can be enabled/disabled at run time
- Macro expanded code with constants
- Optimizations
• Idea: use constant propagation to decide which
branches might be taken
■ Fits in neatly with SSA form
Conditional Constant Propagation
• So far, we’ve been hazy about whether data flow
facts are associated with nodes or edges
■ Advantage of nodes: may be fewer of them ■ (^) Advantage of edges: can trace differences on multiple paths to same node
• For this problem, we’ll associate facts with edges
Nodes versus Edges
• Keep track of whether edges may be executed
■ (^) Some may not be because they’re on not-taken branch ■ (^) Initially, assume no edges taken ■ (^) At joins, don’t propagate information from not-taken in-edges
• Side comment: Notice that we always, always
start with the optimistic assumption
■ We need proof that a pessimistic fact holds ■ We’re computing a greatest fixpoint
Conditional Execution
CMSC 631, Fall 2004 19
• We need a Φ function at node Z if
■ (^) Two non-null CFG paths that both define v ■ Such that both paths start at two distinct nodes and end at Z
Where do Φ Functions Go?
v := 3 v := 4 Z CMSC 631, Fall 2004 20
Dominance Frontiers: Illustration
Dominated by X X Dominance Frontier of X X P Y CMSC 631, Fall 2004 21
• Y is in the dominance frontier of X iff
■ (^) There exists a path from X to Exit through Y such that Y is the first node not strictly dominated by X
• Equivalently:
■ (^) Y is the first node where a path from X to Exit and a path from Entry to Exit (not going through X) meet
• Equivalently:
■ (^) X dominates a predecessor of Y ■ (^) X does not strictly dominate Y
Dominance Frontiers
CMSC 631, Fall 2004 22
Example
1 2 3 4 5 6 7 Entry Exit
• Two components to DF(X):
■ DFlocal(X) = {Y succ(X) | X> Y}
- Any child of X not (strictly) dominated by X is in DF(X) ■ ■ (^) Let Z be such that idom(Z) = X
- idom(Z) is the parent of Z in the dominator tree ■ DFup(Z) = {Y^ DF(Z) | X>Y}
- Nodes from DF(Z) that are not strictly dominated by X are also in DF(X)
Computing Dominance Frontiers
• Suppose Y DF(X)
■ (^) Then there is a U pred(Y) such that X≥U, X>Y ■ If^ U=X,^ then^ U^ DFlocal(X) = {Y^ succ(X) | X>^ Y} ■ Otherwise U≠X
- Then there is a node^ Z^ such that^ idom(Z)=X^ and^ Z≥U
- Since^ X>Y,^ Z>Y,^ hence^ Y^ DF(Z) ■ Therefore^ Y^ DFup(Z) = {Y^ DF(Z) | X>Y}
Why Is This Sufficient?
X/U Y X Z U Y
CMSC 631, Fall 2004 25
• Let sdom(X) = {Y | X>Y}
• In a postorder traversal on dominator tree
■ (^) DF(X) = succ(X) - sdom(X)
- I.e.,^ DF(X) = DFlocal(X) ■ (^) For each Z such that idom(Z) = X do
- DF(X) = DF(X) (DF(Z) - sdom(X))
- I.e.,^ DF(X) = DF(X)^ DFup(Z)
Algorithm
CMSC 631, Fall 2004 26
• In a postorder traversal on dominator tree
■ DF(X) = succ(X) ■ (^) For each Z such that idom(Z) = X do
- DF(X) = DF(X)^ DF(Z) ■ DF(X) = DF(X) - sdom(X) ■
• See paper for another equivalent algorithm that
runs in O(E+|DF|)
Equivalent Algorithm
CMSC 631, Fall 2004 27
• Step 1: Compute the dominance frontier
• Step 2: Use dominance frontier to place Φ
nodes
• Step 3: Rename variables so only one definition
per name
Computing SSA Form
CMSC 631, Fall 2004 28
• Let S be the set of nodes that define v
• Need to place Φ function in every node in DF(S)
■ Recall, those are all the places where the definition of v in S and some other definition of v may meet
• But a Φ function adds another definition of v!
■ (^) v := Φ(v, ..., v)
• So, iterate
■ DF 1 = DF(S)
■ DFi+1 = DF(S^ DFi)
Step 2: Placing Φ Functions for v
Example
Entry 1 : x := 3 2 3 5 : x := 4 6 9 11 4 7 8 10 Exit = need Φ function 1 2 3 4 5 6 9 7 8 10 11
• Top-down (DFS) traversal of dominator tree
■ (^) At definition of v, push new # for v onto the stack ■ (^) When leaving node with definition of v, pop stack ■ Intuitively: Works because there’s a Φ function, hence a new definition of v, just beyond region dominated by definition
• Can be done in O(E+|DF|) time
■ (^) Linear in size of CFG with Φ functions
Step 3: Renaming Variables
CMSC 631, Fall 2004 37
• For each statement S, let
■ MustMod(S) = variables always modified by S ■ (^) MayMod(S) = variables sometimes modified by S
- So if^ v^ MayMod(S),^ then^ S^ must not modify^ v ■ MayUse(S) = variables sometimes used by S
• Then assume that statement S
■ writes to MayMod(S) ■ (^) reads MayUse(S) (MayMod(S) - MustMod(S))
• Convincing? We’ll talk more about pointers
later in the course
Pointers
CMSC 631, Fall 2004 38
• Y is control dependent on X if whether Y is
executed depends on a test at X
• A, B, and C are control dependent on X
Control Dependence
X A B C
• Y postdominates X if every path from X to Exit
contains Y
■ I.e., if X is executed, then Y is always executed ■
• Then,Y is control dependent on X if
■ There is a path^ X→Z 1 →···→Zn→Y^ such that^ Y postdominates all Zi and ■ (^) Y does not postdominate X ■ (^) I.e.,there is some path from X on which Y is always executed, and there is some path on which Y is not executed
Postdominators and Control
Dependence
• Postdominators are just dominators on the CFG
with the edges reversed
• To see what Y is control dependent on, we want
to find the Xs such that in the reverse CFG
■ There is a path^ X←Z 1 ←···←Zn←Y^ where
• I.e., we want to find DF(Y) in the reverse CFG!
Dominance Frontiers, Take 2
