More refined representations Control dependence graph Problem: - PDF document

More refined representations Control dependence graph Problem: control-flow edges in CFG overspecify evaluation Program dependence graph (PDG): order data dependence graph + control dependence graph (CDG) [Ferrante, Ottenstein, & Warren, TOPLAS 87] Solution: introduce more refined notions w/ fewer constraining edges that still capture required orderings Idea: represent controlling conditions directly • side-effects occur in proper order • complements data dependence representation • side-effects occur only under right conditions A node (basic block) Y is control-dependent on another X iff X determines whether Y executes, i.e. • there exists a path from X to Y s.t. every node in the path Some ideas: other than X & Y is post-dominated by Y • explicit control dependence edges, • X is not post-dominated by Y control-equivalent regions, control-dependence graph (PDG) • operators as nodes (Click, VDG, Whirlwind, etc.) Control dependence graph: • computable φ -function operator nodes Y proper descendant of X iff Y control-dependent on X • label each child edge with required branch condition • control dependence via data dependence (VDG) • group all children with same condition under region node Two sibling nodes execute under same control conditions ⇒ can be reordered or parallelized, as data dependences allow (Challenging to “sequentialize” back into CFG form) Craig Chambers 125 CSE 501 Craig Chambers 126 CSE 501 Example An example with a loop 1 y := p + q B1 2 x > 0? T F B2 B3 3 a := x * y 4 a := y - 2 5 w := y / q B4 6 x > 0? T F 7 b := 1 << w B5 B6 8 r := a % b B7 Craig Chambers 127 CSE 501 Craig Chambers 128 CSE 501

Operators as nodes Example Before: nodes in CFG were simple assignments p := &r; • could have operations on r.h.s. x := *p; • used variable names to refer to other values a := x * y; w := x; Alternative: treat the operators themselves as the nodes x := a + a; • refer directly other other nodes for their operands v := y * w; a := v * 2; Node ::= Constant // 0 operands | Var // 0 operands | & Var // 0 operands | Unop // 1 operand | Binop // 2 operands | * (ptr deref) // 1 operand | . (field deref) // 1 operand | [] (array deref) // 2 operands | φ // n operands | Fn () // n operands | Var := (var assn) // 1 operand | *:= (ptr assn) // 2 operands Flow of data captured directly in operand dataflow edges Also have control flow edges sequencing these nodes • or some more refined control dependence edges Craig Chambers 129 CSE 501 Craig Chambers 130 CSE 501 An improvement Another improvement Bypass variable stores and loads "Value numbering": merge all nodes that compute the same result • i.e., build def/use chains • same operator • pure operator Treat variable names as (temporary) labels on nodes • same data operands (recursively) • a variable reference implemented by an edge from the node with that label • same control dependence conditions • a variable assignment shifts the label Implements (local) CSE The nodes themselves become the subscripted variables of SSA form Can do this bottom-up as nodes are initially constructed • "hash cons’ing" Each computation has its own name (i.e., itself) In face of possibly cyclic data dependence edges, an optimistic algorithm can get better results [Alpern et al. 88] Would like to support algebraic identities, too, e.g. • commutative operators • x+x = x*2 • associativity, distributivity Craig Chambers 131 CSE 501 Craig Chambers 132 CSE 501

Another example The example, in SSA form y := p + q; y := p + q; if m > 1 then if m > 1 then a := y * x; a 1 := y * x; b 1 := a 1 ; b := a; else else b 2 := x - 2; a 2 := b 2 ; b := x - 2; a 3 := φ (a 1 ,a 2 ); a := b; b 3 := φ (b 1 ,b 2 ); endif if m < 1 then if m < 1 then d 1 := y * x; d := y * x; else else d 2 := x - 2; d := x - 2; d 3 := φ (d 1 ,d 2 ); endif w := a / r; w := a 3 / r; u := b / r; u := b 3 / r; t := d / r; t := d 3 / r; if m > 1 then if m > 1 then c := y * x; c 1 := y * x; else else c := x - 2; c 3 := x - 2; endif c 3 := φ (c 1 ,c 2 ); z := c / r; z := c 3 / r; Craig Chambers 133 CSE 501 Craig Chambers 134 CSE 501 An improvement Value dependence graphs φ -functions are treated poorly [Weise, Crew, Ernst, & Steensgaard, POPL 94] • impure, since don’t know when they’re the same • even if they have the same operands Idea: represent all dependences, and are in the same control equivalent region! including control dependences, as data dependences + simple, direct dataflow-based representation Fix: give them an additional input: the selector value of all “interesting” relationships (now called select nodes, sometimes written as γ ) • analyses become easier to describe & reason about • e.g., a boolean, for a 2-input φ − harder to sequentialize into CFG • e.g., an integer for an n -input φ Control dependences as data dependences: φ -functions now are pure functions! • control dependence on order of side-effects ⇒ data dependence on reading & writing to global Store • optimizations to break up accesses to single Store into separate independent chunks An approximation, due to Click: (e.g. a single variable, a single data structure) use merge node in CFG as proxy for selector input • control dependence on outcome of branch − fewer equivalences ⇒ a select node, taking test, then, and else inputs + easier to translate back into CFG form ⇒ demand-driven evaluation model Loops implemented as tail-recursive calls to local procedures Apply CSE, folding, etc. as nodes are built/updated Craig Chambers 135 CSE 501 Craig Chambers 136 CSE 501

VDG for example, after store splitting Sequentialization y := p + q; if x > 0 then a := x * y else a := y - 2; How to generate code for a soup of operator nodes? w := y / q; • need to sequentialize back into regular CFG if x > 0 then b := 1 << w; r := a % b; Find an ordering that respects dependences (data and control) Hard with arbitrary graph x p q b • can get cycles with full PDG, VDG transforms + • may need to duplicate code to get a legal schedule y 2 Click’s representation: keeps original CFG around as a guide * - / − limits transformations/optimizations possible a 1 a 2 w + turns sequentialization problem into simpler placement 0 1 problem γ > << a γ b % r Craig Chambers 137 CSE 501 Craig Chambers 138 CSE 501 Placement Example Goal: assign each operation to i := 0; the least-frequently-executed basic block while ... do that respects its data dependences x := i * b; • φ -nodes tied to their original basic block if ... then w := c * c; Hoist operations out of loops where possible y := x + w; Push operations into conditionals where possible else y := 9; end print(y); i := i + 1; end Craig Chambers 139 CSE 501 Craig Chambers 140 CSE 501

Example, in SSA form i 1 := 0; while ... do i 3 := φ (i 1 , i 2 ); x := i 3 * b; if ... then w := c * c; y 1 := x + w; else y 2 := 9; end y 3 := φ (y 1 , y 2 ); print(y 3 ); i 2 := i 3 + 1; end Craig Chambers 141 CSE 501