Construction of Static Single-Assignment Form

Size: px

Start display at page:

Download "Construction of Static Single-Assignment Form"

Maria Dina Martin
5 years ago
Views:

Students enrolled in Comp 506 at Rice University have explicit permission to make copies of these materials for their personal use.

1 COMP 506 Rice University Spring 2018 Construction of Static Single-Assignment Form Part II source IR IR target code Front End Optimizer Back End code Copyright 2018, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp 506 at Rice University have explicit permission to make copies of these materials for their personal use. Faculty from other educational institutions may use these materials for nonprofit educational purposes, provided this copyright notice is preserved Section numbers refer to EaC2e.

2 SSA Construction Algorithm (High-level sketch) Conceptually, the algorithm is simple 1. Insert ø-functions where distinct values come together 2. Rename values to maintain the principle of static single assignment that s all... of course, there is some bookkeeping to be done... COMP 506, Spring

SSA Construction (semi-pruned SSA) 1. Insert ø-functions a. Calculate dominance frontier b.

Using dominance frontiers, insert ø-functions for each global name Creates the iterated dominance frontier " global name n " block b

Critical, but moderately complex; DFs guide ø-function insertion Compute list of blocks where each name is assigned & use as a

3 SSA Construction (semi-pruned SSA) 1. Insert ø-functions a. Calculate dominance frontier b. Find global names For each name, build a list of blocks that define it c. Using dominance frontiers, insert ø-functions for each global name Creates the iterated dominance frontier " global name n " block b in which n is assigned " block d in b s dominance frontier insert a ø-function for n in d add d to n s list of defining blocks Critical, but moderately complex; DFs guide ø-function insertion Compute list of blocks where each name is assigned & use as a worklist This adds to the worklist Use a checklist to avoid putting blocks on the worklist twice; Use another checklist to avoid inserting the same ø-function twice. Algorithm, except for 1.b, is from CFRWZ [110]. See in EaC2e. COMP 506, Spring

block, b 1 counter per global name for the subscript a. Generate unique names for the result of each ø-function b.

Rewrite definition by incrementing the version number & pushing it on the stack c.

4 SSA Construction (semi-pruned SSA) 2. Rename variables in a pre-order walk over the dominator tree (use an array of stacks, one stack per global name) Starting with the root block, b 1 counter per global name for the subscript a. Generate unique names for the result of each ø-function b. Rewrite each operation in the block i. Rewrite uses of global names with the current version number (from its stack) ii. Rewrite definition by incrementing the version number & pushing it on the stack c. Fill in ø-function parameters for successor blocks of b Reset the state to d. Recurse on b s children in the dominator tree IDOM(b) s e-o-b state e. <on exit from block b> pop the names generated in b from the stacks Need the end-of-block names for this path Algorithm, except for 1.b, is from CFRWZ [110]. See in EaC2e. COMP 506, Spring

5 SSA Construction (semi-pruned SSA) 1. Insert ø-functions a. Calculate dominance frontier focus on this step b. Find global names For each name, build a list of blocks that define it c. Using dominance frontiers, insert ø-functions for global names " global name n " block b in which n is assigned " block d in b s dominance frontier insert a ø-function for n in d add d to n s list of defining blocks COMP 506, Spring

6 Dominance Frontiers & ø-function Insertion Where does an assignment in block n induce a ø-function? If n DOM m, there is no need for a ø-function in m The definition in n blocks any previous definition from reach m If m has multiple predecessors and n dominates one of them, but not all of them, then m needs a ø-function for each name defined in n (Def n of DOM) More formally, m is in the dominance frontier of n, written m DF(n), iff 1. p predecessors(m) such that n DOM(p), and 2. n does not strictly dominate m (n DOM(m) { m }) Define Strict IDOM(x) The dominance frontier precisely describes where to insert ø-functions: A definition in block n requires a ø-function in each block in DF(n) Strict dominance allow a ø-function at the head of a single-block loop. COMP We say 506, x Spring STRICT 2018 IDOM(y) if x IDOM(y) and x y. 6

7 Dominance Frontiers n n p q p q m m All of m s CFG predecessors are dominated by n n DOM(m) m DF(n) n DOM(m) & n DOM(p) m DF(n) COMP If n DOM(m), 506, Spring n DOM(p), 2018 & n DOM(q), then m does not matter to DF(n) 7

8 Dominance & Dominance Frontiers Example B 0 B 2 B 3 Results of iterative solution for DOM DOM 0 0,1 0,1,2 0,1,3 0,1,3,4 0,1,3,5 0,1,3,6 0,1,7 IDO M B 4 B 5 Control Flow Graph COMP 506, Spring

9 Dominance & Dominance Frontiers Example B 0 B 2 B 3 Results of iterative solution for DOM DOM 0 0,1 0,1,2 0,1,3 0,1,3,4 0,1,3,5 0,1,3,6 0,1,7 IDO M B 4 B 5 Dominator Tree COMP 506, Spring

10 Dominance & Dominance Frontiers Example B 0 x ø(...) B 2 B 3 x B... 4 B 5 x ø(...) Dominance Frontiers & ø-function Insertion A definition at n forces a ø-function at m iff n Ï DOM(m) but n Î DOM(p) for some p Î preds(m) DF(n ) is fringe just beyond region n dominates DOM 0 0,1 0,1,2 0,1,3 0,1,3, 4 0,1,3,5 0,1,3, 6 DF (strict) DF(4) is {6}, so in 4 forces ø-function in 6 x ø (...) in 6 forces ø-function in DF(6) = {7} 0,1,7 Control Flow Graph in 7 forces ø-function in DF(7) = {1} in 1 forces ø-function in DF(1) = {1} (halt the ø-function is already there ) For each assignment, we insert the ø-functions COMP 506, Spring

11 Dominance & Dominance Frontiers Example B 0 B 2 B 3 B 4 B 5 Control Flow Graph DOM 0 0,1 0,1,2 0,1,3 0,1,3,4 0,1,3,5 0,1,3,6 0,1,7 Strict DF Computing Dominance Frontiers Only join points are in DF(n) for some n Leads to a simple, intuitive algorithm for computing dominance frontiers For each join point x (i.e., preds(x) > 1) For each CFG predecessor p of x Run from p to IDOM(x) in the dominator tree, & add x to DF(n) for each n from p up to but not STRICT IDOM(x) Consider, which is a join point B 2 is a CFG predecessor & not IDOM( ) DF(B 2 ) is B 2 s dom. tree ancestor, but is IDOM( ) stop is a CFG predecessor & not IDOM( ) DF( ) B 3 is B 2 s dom. tree ancestor & not IDOM( ) DF( ) is B 2 s dom. tree ancestor, but is IDOM( ) stop COMP 506, Spring

12 Dominance & Dominance Frontiers Example B 0 B 2 B 3 B 4 B 5 Control Flow Graph DOM 0 0,1 0,1,2 0,1,3 0,1,3,4 0,1,3,5 0,1,3,6 0,1,7 Strict DF Computing Dominance Frontiers Only join points are in DF(n) for some n Leads to a simple, intuitive algorithm for computing dominance frontiers For each join point x (i.e., preds(x) > 1) For each CFG predecessor p of x Run from p to IDOM(x) in the dominator tree, & add x to DF(n) for each n from p up to but not IDOM(x) For some applications (other than building SSA), we need post-dominance, the post-dominator tree, and reverse dominance frontiers, RDF(n) u Just dominance on the reverse CFG u Reverse the edges & add unique exit node We will use these ideas in dead code elimination COMP 506, Spring

13 SSA Construction (semi-pruned SSA) 1. Insert ø-functions a. Calculate dominance frontier b. Find global names focus on this step For each name, build a list of blocks that define it c. Using dominance frontiers, insert ø-functions for global names " global name n " block b in which n is assigned " block d in b s dominance frontier insert a ø-function for n in d add d to n s list of defining blocks A global name is LIVE on entry to some block. Step 1.b is not in the CFRWZ algorithms [110]. It shrinks the set of names for which ø-functions are inserted [50]. COMP 506, Spring

SSA Construction (semi-pruned SSA) Finding global names The difference between minimal SSA [110] and semi-pruned SSA [50] Semi-pruned only insert ø-functions for names that are LIVE on entry to some

14 SSA Construction (semi-pruned SSA) Finding global names The difference between minimal SSA [110] and semi-pruned SSA [50] Semi-pruned only insert ø-functions for names that are LIVE on entry to some block 1 Shrinks the name space, the number of ø-functions, & the number of stacks Savings in construction time more than pays for the cost of the analysis Building semi-pruned is faster, in practice, than building minimal For each global name, need a list of blocks where it is defined That list drives ø-function insertion Block b defines x implies a ø-function for x in every c DF(b) Pruned SSA adds a test to see if x is globally LIVE at the insertion point Occasionally, building pruned SSA is faster than building semi-pruned SSA. Any algorithm that has non-linear behavior in the number of Ø-functions will have a size where pruned is the SSA flavor of choice. 1 COMP Can use 506, a Spring local 2018 notion of LIVE an upward exposed variable 14

15 SSA Construction (semi-pruned SSA) 1. Insert ø-functions a. Calculate dominance frontier b. Find global names For each name, build a list of blocks that define it c. Using dominance frontiers, insert ø-functions for global names " global name n " block b in which n is assigned " block d in b s dominance frontier insert a ø-function for n in d add d to n s list of defining blocks COMP 506, Spring

16 Example Lots of assignments Expression details elided B 0 i a c B 2 b c d B 4 B 3 d a d B 5 c Assume that a, b, c, & d are defined somewhere before B 0 y a+b z c+d i i+1 b Strict DF COMP 506, Spring

17 Example Afterø-function insertion Lots of new ops Ready for renaming B 0 i a Ø(a,a) b Ø(b,b) c Ø(c,c) d Ø(d,d) i Ø(i,i) a c B 2 b c d B 4 B 3 d a d B 5 c Excluding local names (semi-pruned) avoids ø- functions for x & y in Strict DF a Ø(a,a) b Ø(b,b) c Ø(c,c) d Ø(d,d) y a+b z c+d i i+1 d Ø(d,d) c Ø(c,c) b COMP 506, Spring Earlier example shows iterated insertion. (Slide 10)

18 SSA Construction One Final Point About ø-function Insertion ø-functions have an unusual semantics When execution enters a block, all the ø-functions evaluate their arguments, in parallel, and then perform their assignments, in parallel This behavior allows the compiler to manipulate ø-functions without worrying about the order in which they appear at the head of a block The parallel semantics of ø-functions will introduce complications when the compiler has to translate code in SSA form back into executable code (see in EaC2e) COMP 506, Spring

19 SSA Construction (semi-pruned SSA) 2. Rename variables in a pre-order walk over the dominator tree (use an array of stacks, one stack per global name) Starting with the root block, b a. Generate unique names for the result of each ø-function b. Rewrite each operation in the block i. Rewrite uses of global names with the current version number (from its stack) ii. Rewrite definition by incrementing the version number & pushing it on the stack c. Fill in ø-function parameters for successor blocks of b d. Recurse on b s children in the dominator tree e. <on exit from block b> pop the names generated in b from the stacks COMP 506, Spring

20 SSA Construction (semi-pruned SSA) Adding the details... for each global name i counter[i] 0 stack[i] Ø call Rename(n 0 ) NewName(n) i counter[n] counter[n] counter[n] + 1 push n i onto stack[n] return n i Minor engineering nit: assume, up front, that all names were converted to unique small integers Rename(b) for each ø-function in b, x ø ( ) rename x as NewName(x) for each operation x y op z in b rewrite y as top(stack[y]) rewrite z as top(stack[z]) rewrite x as NewName(x) for each successor of b in the CFG rewrite appropriate ø parameters for each successor s of b in dom. tree Rename(s) for each operation x y op z in b or each phi-function pop(stack[x]) COMP 506, Spring

B 0 i Example a Ø(a,a) b Ø(b,b) c Ø(c,c) d Ø(d,d) i

Ø(d,d) c Ø(c,c) b Counters Stacks a b c d i 1 1 1 1 0

21 B 0 i Example a Ø(a,a) b Ø(b,b) c Ø(c,c) d Ø(d,d) i Ø(i,i) a c Before processing B 0 B 2 b c d B 4 B 3 d a d B 5 c Assume a, b, c, & d defined before B 0 a Ø(a,a) b Ø(b,b) c Ø(c,c) d Ø(d,d) y a+b z c+d i i+1 d Ø(d,d) c Ø(c,c) b Counters Stacks a b c d i a 0 b 0 c 0 d 0 i has not been defined COMP 506, Spring

22 B 0 i 0 Example a Ø(a 0,a) b Ø(b 0,b) c Ø(c 0,c) d Ø(d 0,d) i Ø(i 0,i) a c End of B 0 B 2 b c d B 4 B 3 d a d B 5 c a Ø(a,a) b Ø(b,b) c Ø(c,c) d Ø(d,d) y a+b z c+d i i+1 d Ø(d,d) c Ø(c,c) b Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 COMP 506, Spring

23 B 0 i 0 Example a 1 Ø(a 0,a) b 1 Ø(b 0,b) c 1 Ø(c 0,c) d 1 Ø(d 0,d) i 1 Ø(i 0,i) a 2 c 2 End of B 2 b c d B 4 B 3 d a d B 5 c a Ø(a,a) b Ø(b,b) c Ø(c,c) d Ø(d,d) y a+b z c+d i i+1 d Ø(d,d) c Ø(c,c) b Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 a 2 c 2 COMP 506, Spring

24 B 0 i 0 Example a 1 Ø(a 0,a) b 1 Ø(b 0,b) c 1 Ø(c 0,c) d 1 Ø(d 0,d) i 1 Ø(i 0,i) a 2 c 2 End of B 2 B 2 b 2 c 3 d 2 B 4 B 3 d a d B 5 c a Ø(a 2,a) b Ø(b 2,b) c Ø(c 3,c) d Ø(d 2,d) y a+b z c+d i i+1 d Ø(d,d) c Ø(c,c) b Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 a 2 b 2 c 2 d 2 c 3 COMP 506, Spring

25 B 0 i 0 Example a 1 Ø(a 0,a) b 1 Ø(b 0,b) c 1 Ø(c 0,c) d 1 Ø(d 0,d) i 1 Ø(i 0,i) a 2 c 2 Before starting B 3 B 2 b 2 c 3 d 2 B 4 B 3 d a d B 5 c a Ø(a 2,a) b Ø(b 2,b) c Ø(c 3,c) d Ø(d 2,d) y a+b z c+d i i+1 d Ø(d,d) c Ø(c,c) b i 100 Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 a 2 c 2 COMP 506, Spring

26 B 0 i 0 Example a 1 Ø(a 0,a) b 1 Ø(b 0,b) c 1 Ø(c 0,c) d 1 Ø(d 0,d) i 1 Ø(i 0,i) a 2 c 2 End of B 3 B 2 b 2 c 3 d 2 B 4 B 3 d a 3 d 3 B 5 c a Ø(a 2,a) b Ø(b 2,b) c Ø(c 3,c) d Ø(d 2,d) y a+b z c+d i i+1 d Ø(d,d) c Ø(c,c) b Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 a 2 c 2 a 3 d 3 COMP 506, Spring

27 B 0 i 0 Example a 1 Ø(a 0,a) b 1 Ø(b 0,b) c 1 Ø(c 0,c) d 1 Ø(d 0,d) i 1 Ø(i 0,i) a 2 c 2 End of B 4 B 2 b 2 c 3 d 2 B 4 d 4 B 3 a 3 d 3 B 5 c a Ø(a 2,a) b Ø(b 2,b) c Ø(c 3,c) d Ø(d 2,d) y a+b z c+d i i+1 d Ø(d 4,d) c Ø(c 2,c) b Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 a 2 c 2 a 3 d 3 d 4 COMP 506, Spring

28 B 0 i 0 Example a 1 Ø(a 0,a) b 1 Ø(b 0,b) c 1 Ø(c 0,c) d 1 Ø(d 0,d) i 1 Ø(i 0,i) a 2 c 2 End of B 5 B 2 b 2 c 3 d 2 B 3 a 3 d 3 B 4 B 5 c 4 d 4 a Ø(a 2,a) b Ø(b 2,b) c Ø(c 3,c) d Ø(d 2,d) y a+b z c+d i i+1 d Ø(d 4,d 3 ) c Ø(c 2,c 4 ) b Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 a 2 c 2 d 3 a 3 c 4 COMP 506, Spring

29 B 0 i 0 Example a 1 Ø(a 0,a) b 1 Ø(b 0,b) c 1 Ø(c 0,c) d 1 Ø(d 0,d) i 1 Ø(i 0,i) a 2 c 2 End of B 2 b 2 c 3 d 2 d 4 B 3 a 3 d 3 B 4 B 5 c 4 a Ø(a 2,a 3 ) b Ø(b 2,b 3 ) c Ø(c 3,c 5 ) d Ø(d 2,d 5 ) y a+b z c+d i i+1 d 5 Ø(d 4,d 3 ) c 5 Ø(c 2,c 4 ) b 3 Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 a 2 b 3 c 2 d 3 a 3 c 5 d 5 COMP 506, Spring

30 B 0 i 0 Example a 1 Ø(a 0,a) b 1 Ø(b 0,b) c 1 Ø(c 0,c) d 1 Ø(d 0,d) i 1 Ø(i 0,i) a 2 c 2 Before start of B 2 b 2 c 3 d 2 d 4 B 3 a 3 d 3 B 4 B 5 c 4 a Ø(a 2,a 3 ) b Ø(b 2,b 3 ) c Ø(c 3,c 5 ) d Ø(d 2,d 5 ) y a+b z c+d i i+1 d 5 Ø(d 4,d 3 ) c 5 Ø(c 2,c 4 ) b 3 Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 a 2 c 2 Popped COMP 506, all the Spring way back 2018to end of 30

31 B 0 i 0 Example a 1 Ø(a 0,a 4 ) b 1 Ø(b 0,b 4 ) c 1 Ø(c 0,c 6 ) d 1 Ø(d 0,d 6 ) i 1 Ø(i 0,i 2 ) a 2 c 2 After B 2 b 2 c 3 d 2 d 4 B 3 a 3 d 3 B 4 B 5 c 4 a 4 Ø(a 2,a 3 ) b 4 Ø(b 2,b 3 ) c 6 Ø(c 3,c 5 ) d 6 Ø(d 2,d 5 ) y a 4 +b 4 z c 6 +d 6 i 2 i 1 +1 d 5 Ø(d 4,d 3 ) c 5 Ø(c 2,c 4 ) b 3 Counters Stacks a b c d i a 0 b 0 c 0 d 0 i 0 a 1 b 1 c 1 d 1 i 1 b 4 a 2 c 2 d 6 i 2 a 4 c 6 COMP 506, Spring

32 B 0 i 0 Example a 1 Ø(a 0,a 4 ) b 1 Ø(b 0,b 4 ) c 1 Ø(c 0,c 6 ) d 1 Ø(d 0,d 6 ) i 1 Ø(i 0,i 2 ) a 2 c 2 After renaming Semi-pruned SSA form No Ø s for y or z in We are done B 2 b 2 c 3 d 2 d 4 B 3 a 3 d 3 B 4 B 5 c 4 d 5 Ø(d 4,d 3 ) c 5 Ø(c 2,c 4 ) b 3 a 4 Ø(a 2,a 3 ) b 4 Ø(b 2,b 3 ) c 6 Ø(c 3,c 5 ) d 6 Ø(d 2,d 5 ) y a 4 +b 4 z c 6 +d 6 i 2 i 1 +1 COMP 506, Spring

33 Flavors of SSA We have seen naïve and semi-pruned SSA. Are there other flavors? Naïve, minimal, semi-pruned, pruned are all well known They differ in the number of extraneous ø-functions that they insert Extra Ø-functions Reason Naïve Stupidly many ø-functions Did not use DF in insertion Minimal Name defined & used in 1 block still gets ø-functions Semi-pruned Global names get Ø-functions even when dead Considers full name space & ignores liveness Uses an approximation to substitute for liveness Pruned 1 Explicit test for liveness Solves & uses LIVE The improvements come from more careful ø-function insertion in step 1 In practice the modifications to step 1 are not complex 1 J.D. Choi, R. Cytron, & J. Ferrante, Automatic construction of sparse data flow evaluation graphs, POPL 91, pages COMP 506, Spring

34 One Last Point, If Time Permits Interpreting SSA Form as a Graph We can interpret the SSA Form of the code as a graph sum = 0 do i = 1 to 100 sum = sum + a(i) end do A simple example loop Short-lived temporary values loadi 0 Þ r s0 loadi 1 Þ r i0 loadi 100 Þ r 100 loop: phi r s0,r s2 Þ r s1 phi r i0,r i2 Þ r i1 subi r i1,1 Þ r 1 multi r 1,4 Þ r 2 addi r 2,@a Þ r 3 load r 3 Þ r 4 add r 4,r s1 Þ r s2 addi r i1,1 Þ r i2 cmp_lt r i2,r 100 Þ r 5 cbr r 5 loop,exit exit:... The example in semi-pruned SSA Form COMP 506, Spring

35 Interpreting SSA Form as a Graph We can interpret the SSA Form of the code as a graph Short-lived temporary values loadi 0 Þ r s0 loadi 1 Þ r i0 loadi 100 Þ r 100 loop: phi r s0,r s2 Þ r s1 phi r i0,r i2 Þ r i1 subi r i1,1 Þ r 1 multi r 1,4 Þ r 2 addi r 2,@a Þ r 3 load r 3 Þ r 4 add r 4,r s1 Þ r s2 addi r i1,1 Þ r i2 cmp_lt r i2,r 100 Þ r 5 cbr r 5 loop,exit exit:... The example in semi-pruned SSA Form load The SSA Form viewed as a Graph COMP 506, Spring r i0 r i1 1 Ø + r i2 r r 2 + r 3 cmp_lt r 5 cbr pc 100 r 4 r s0 r s1 r s2 0 Ø +

Lecture 11: Data Flow Analysis III

CS 515 Programming Language and Compilers I Lecture 11: Data Flow Analysis III (The lectures are based on the slides copyrighted by Keith Cooper and Linda Torczon from Rice University.) Zheng (Eddy) Zhang