A generic worklist analysis algorithm Advanced program - PDF document

A generic worklist analysis algorithm Advanced program representations Maintain a mapping from each program point to info at that point Goal: • optimistically initialize all pp’s to T • more effective analysis Set other pp’s (e.g. entry/exit point) to other values, if desired • faster analysis • easier transformations Maintain a worklist of nodes whose flow functions needs to be evaluated Approach: • initialize with all nodes in graph more directly capture important program properties • e.g. data flow, independence While worklist nonempty do Pop node off worklist Evaluate node’s flow function, given current info on predecessor/successor pp’s, allowing it to change info on predecessor/successor pp’s If any pp’s changed, then put adjacent nodes on worklist (if not already there) For faster analysis, want to follow topological order • number nodes in topological order • pop nodes off worklist in increasing topological order It Just Works! Craig Chambers 73 CSE 501 Craig Chambers 74 CSE 501 Examples Def/use chains CFG: Def/use chains directly linking defs to uses & vice versa + simple to build + directly captures data flow for analysis + complete • e.g. constant propagation, live variables easy + no derived info to keep up to date during transformations − ignores control flow − computing info is slow and/or ineffective • misses some optimization opportunities, since it assumes all paths taken • lots of propagation of big sets/maps • not executable by itself, since it doesn’t include control dependence links • not appropriate for some optimizations, such as CSE and code motion − must update after transformations • but just thin out chains − space-consuming, in worst case: O( E 2 V ) − can have multiple defs of same variable in program, multiple defs can reach a use • complicates analysis Craig Chambers 75 CSE 501 Craig Chambers 76 CSE 501

Example Static Single Assignment (SSA) form [Alpern, Rosen, Wegman, & Zadeck, two POPL 88 papers] x := ... y := ... Invariant: at most one definition reaches each use ... x ... Constructing equivalent SSA form of program: 1. Create new target names for all definitions x := x + y x := ... 2. Insert pseudo-assignments at merge points y := y + 1 reached by multiple definitions of same source variable: ... x ... ... x ... x n := φ ( x 1 ,..., x n ) 3. Adjust uses to refer to appropriate new names ... y ... ... y ... ... y ... ... y ... Craig Chambers 77 CSE 501 Craig Chambers 78 CSE 501 Example Comparison + lower worst-case space cost than def/use chains: O( EV ) x := ... y := ... + algorithms simplified by exploiting ... x ... single assignment property: • variable has a unique meaning independent of program point • can treat variable & value synonymously x := x + y x := ... y := y + 1 + transformations not limited by reuse of variable names ... x ... ... x ... • can reorder assignments to same source variable, without affecting dependences of SSA version − still not executable by itself − still must update/reconstruct after transformations ... y ... − inverse property (static single use) not provided ... y ... ... y ... • dependence flow graphs [Pingali et al. ] and value dependence graphs [Weise et al. ] fix this, with single-entry, single-exit (SESE) region analysis ... y ... Very popular in research compilers, analysis descriptions Craig Chambers 79 CSE 501 Craig Chambers 80 CSE 501

Common subexpression elimination Specification At each program point, compute set of available expressions : All possible available expressions: AvailableExprs = { expr → var | ∀ expr ∈ Expr, ∀ var ∈ Var} map from expression to variable holding that expression • e.g. {a+b → x, -c → y, *p → z} • Var = set of all variables in procedure • Expr = set of all right-hand-side expressions in procedure CSE transformation using AE analysis results: [is this a function from Exprs to Vars, or just a relation?] if a+b → x available before y := a+b , transform to y := x Domain AV = < Pow(AvailableExprs), ≤ AV > ae 1 ≤ AV ae 2 ⇔ • top: • bottom: • meet: • lattice height: Craig Chambers 81 CSE 501 Craig Chambers 82 CSE 501 Constraints Example AE x := y op z : i := a + b x := i * 4 j := i y := i * 4 i := c i := i + 1 z := j * 4 AE x := y : m := b + a w := 4 * m Initial conditions at program points? What direction to do analysis? Can use bit vectors? Craig Chambers 83 CSE 501 Craig Chambers 84 CSE 501

Exploiting SSA form Example Problem: previous available expressions overly sensitive to i := a + b name choices, operand orderings, renamings, assignments, x := i * 4 ... A solution: j := i Step 1: convert to SSA form i := c y := i * 4 z := j * 4 i := i + 1 • distinct values have distinct names ⇒ can simplify flow functions to ignore assignments AE SSA x := y op z : m := b + a w := 4 * m Step 2: do copy propagation • same values (usually) have same names ⇒ avoid missed opportunities Step 3: adopt canonical ordering for commutative operators ⇒ avoid missed opportunities Craig Chambers 85 CSE 501 Craig Chambers 86 CSE 501 After SSA conversion, copy propagation, & Loop-invariant code motion operand order canonicalization: Two steps: analysis & transformation i 1 := a 1 + b 1 x 1 := i 1 * 4 Step 1: find invariant computations in loop • invariant: computes same result each time evaluated i 4 := φ (i 1 ,i 3 ) j 1 := i 1 Step 2: move them outside loop i 2 := c 1 y 1 := i 4 * 4 • to top: code hoisting z 1 := i 1 * 4 i 3 := i 4 + 1 • if used within loop • to bottom: code sinking • if only used after loop m 1 := a 1 + b 1 w 1 := m 1 * 4 Craig Chambers 87 CSE 501 Craig Chambers 88 CSE 501

Example Detecting loop-invariant expressions An expression is invariant w.r.t. a loop L iff: x := 3 base cases: y := 4 y := 5 • it’s a constant • it’s a variable use, all of whose defs are outside L z := x * y inductive cases: q := y * y • it’s an idempotent computation all of whose args are loop-invariant w := y + 2 • it’s a variable use with only one reaching def , and the rhs of that def is loop-invariant w := w + 5 p := w + y x := x + 1 q := q + 1 Craig Chambers 89 CSE 501 Craig Chambers 90 CSE 501 Computing loop-invariant expressions Example using def/use chains Option 1: x := 3 • repeat iterative dfa until no more invariant expressions found • to start, optimistically assume all expressions loop-invariant y := 4 y := 5 Option 2: • build def/use chains, z := x * y follow chains to identify & propagate q := y * y invariant expressions w := y + 2 Option 3: • convert to SSA form, w := w + 5 then similar to def/use form p := w + y x := x + 1 q := q + 1 Craig Chambers 91 CSE 501 Craig Chambers 92 CSE 501

Loop-invariant expression detection for SSA form Example using SSA form SSA form simplifies detection of loop invariants, x 1 := 3 since each use has only one reaching definition y 1 := 4 y 2 := 5 An expression is invariant w.r.t. a loop L iff: x 2 = φ (x 1 , x 3 ) base cases: • it’s a constant y 3 = φ (y 1 , y 2 , y 3 ) • it’s a variable use whose single def is outside L z 1 := x 2 * y 3 q 1 := y 3 * y 3 inductive cases: w 1 := y 3 + 2 • it’s an idempotent computation all of whose args are loop-invariant • it’s a variable use w 2 := w 1 + 5 whose single def’s rhs is loop-invariant w 3 = φ (w 1 , w 2 ) p 1 := w 3 + y 3 φ functions are not idempotent x 3 := x 2 + 1 q 2 := q 1 + 1 Craig Chambers 93 CSE 501 Craig Chambers 94 CSE 501 Example using SSA form & preheader Code motion When find invariant computation S: z := x op y , x 1 := 3 want to move it out of loop (to loop preheader) y 1 := 4 y 2 := 5 When is this legal? y 3 = φ (y 1 , y 2 ) Sufficient conditions: • S dominates all loop exits [ A dominates B when x 2 = φ (x 1 , x 3 ) all paths to B must first pass through A ] z 1 := x 2 * y 3 • otherwise may execute S when never executed otherwise q 1 := y 3 * y 3 • can relax this condition, if S has no side-effects or traps, at cost of possibly slowing down program w 1 := y 3 + 2 • S is only assignment to z in loop, & w 2 := w 1 + 5 no use of z in loop is reached by any def other than S • otherwise may reorder defs/uses and change outcome w 3 = φ (w 1 , w 2 ) • unnecessary in SSA form! p 1 := w 3 + y 3 If met, then can move S to loop preheader x 3 := x 2 + 1 • but preserve relative order of invariant computations, q 2 := q 1 + 1 to preserve data flow among moved statements Craig Chambers 95 CSE 501 Craig Chambers 96 CSE 501

Example of need for domination requirement Avoiding domination restriction Requirement that invariant computation dominates exit is strict • nothing in conditional branch can be moved x := 0 • nothing after loop exit test can be moved y := 1 Can be circumvented through other transformations such as loop normalization z != 0? • move loop exit test to bottom of loop Before After x := a * b q := x + y y := x / z i := 0 i := 0 i < N? i < N? x := a / b x := a / b i := i + 1 i := i + 1 i < N? Craig Chambers 97 CSE 501 Craig Chambers 98 CSE 501 Example of data dependence restrictions Example in SSA form “ S is only assignment to z in loop, & Restrictions unnecessary if in SSA form no use of z in loop is reached by any def other than S ” • if reorder defs/uses, generate code along merging arcs to implement φ functions z := 5 z 1 := 5 z 2 := φ (z 1 ,z 4 ) z := z + 1 z 3 := z 2 + 1 S: z := 0 S: z 4 := 0 ... z ... ... z 4 ... Craig Chambers 99 CSE 501 Craig Chambers 100 CSE 501