263-2810: Advanced Compiler Design 3.0 SSA form for arbitrary - PowerPoint PPT Presentation

263-2810: Advanced Compiler Design 3.0 SSA form for arbitrary control flow graphs Thomas R. Gross Computer Science Department ETH Zurich, Switzerland

SSA format § φ funcKons allows us to deal with a basic block that has mulKple predecessors § To turn a program into SSA format § Insert φ func+ons § Determine version to be used as operand § Produce new versions when there is an assignment § Or a φ func+on delivers the correct version § So far: syntacKc approach § Works for well-structured programs § Next: an approach for general control flow graphs § But first: review of concepts for graphs 2

Outline § 3.1 Graphs § 3.2 Approaches to inserKon of φ funcKons § 3.3 Dominance fronKer § 3.4 Algorithm for inserKon of φ funcKons § 3.5 Algorithm for variable renaming § 3.6 Example 3

3.1 Graphs § Control flow graph: central data structure § Nodes: basic blocks (or sequences of straight-line program segments) § Edges: directed, possible control flow § Special nodes § ENTRY: special without predecessor § EXIT: special without successor § Edge from ENTRY to EXIT 4

Dominance § Given a CFG. A node A (or basic block A) dominates node B (basic block B) if A is on every path from ENTRY to B. A dom B A dom A X ¬ dom Y : X does not dominate Y 5

7

9

Immediate dominator § A idom B § A dom B § ∄ X such that A dom X and X dom B (X ≠ A, X ≠ B) 11

Dominator tree § The dominator tree (DT) captures the immediate dominator relaKonship § X idom Y: edge X ➞ Y in DT § There is exactly one immediate dominator § That’s why it’s a tree … § Last dominator on any path from ENTRY 15

Example 2 (Dominator tree) ENTRY A EXIT B C D 17

Terminology § Control flow graph § predecessor § successor § direct (predecessor/successor): There is an edge --- indicates possible control transfer § Example § B direct successor of A § C direct successor of B § A direct predecessor of B § D successor of A § A predecessor of C § C possible predecessor of B § ENTRY → A → B → C → B …. vs ENTRY → A → B → D → EXIT 21

Terminology 2 § Dominator tree § child § parent § ancestor: parent, grandparent, great-grandparent,… § descendant: child, grandchild, great-grandchild, … § Example § A parent of B § B child of A § C child of B § No statement about actual control flow 23 § ENTRY → A → B → D → EXIT

Dominator relaKonship § dom reflexive § X dom X § SomeKmes we want an irreflexive (an0-reflexive) relaKonship § Want to be sure that A dom B implies A ≠ B § X strictly dominates Y: X dom Y and X ≠ Y X ⨠ Y § DisKnguish from (weak) dominaKon: X dom Y X ⨠ Y 24

27

3.2 InserKon of φ funcKons § Where could we insert φ funcKons? § Where should we insert φ funcKons? 29

ENTRY Example graph X = X = = X BB6 EXIT 30

§ Program not well-structured § Insert φ funcKons – OpKon A: § Insert a φ func+on into the block that uses a variable § Example: x is used in basic block BB6 31

33

§ Insert φ funcKons – OpKon B: § Insert a φ func+on as early as possible § Even if there is no use of a variable in basic block § Example: func+ons in BB3, BB5, and BB6 34

36

§ OpKon B: Number of arguments to φ funcKon depends on the number of direct predecessors in CFG § Fixed for a given programming language resp. implementa+on § case/switch statement may result in unlimited number of predecessors unless compiled into cascading set of if-statements § OpKon A: Number of arguments to φ funcKon depends on number of paths that reach a given point § Unbounded § OpKon B preferred by compiler designers 37

Setup § Let us assume there is an iniKal (dedicated) assignment to each variable § For X, Y, Z,… we have X 0 , Y 0 , Z 0 , … § “Placed” into the ENTRY node § “pseudo-assignment” § Benefits § There is at least one assignment on every path § If the RHS of an assignment or expression reads X 0 there is possibly a use of an unini+alized variable 38

CFG nodes with φ funcKons § Consider two nodes A, B § A defines X , B uses X A X = B = X § No funcKon is needed along path from A to B if A ⨠ B 40

§ But A = B is possible. Need to deal with = X X = X = = X § Extend definiKon of dominance from basic blocks (nodes of CFG) to operaKons in basic block § def ini+ons § use s 42

§ DefiniKon (def) d i in block A § Use (use) u j in block B d i ⨠ u j iff d i is in block A, u j is in block B, and d i is the last definiKon along any path from ENTRY to u j § Corrollary: A ⨠ B § Can define d i ⨠ u j as well 43

¬ (d i ⨠ u j ) § ¬ (d i ⨠ u j ): d i does not dominate u j d k d i X = X = u j = X § ∃ at least one path from ENTRY to u j that does not include d i (as the last definiKon of X ) 44

Detailed look § No φ funcKon if d ⨠ u § φ funcKon if no dominance 45

47

Placement of φ funcKons § Look for nodes n 1 , n 2 , … that have these properKes § n 1 , n 2 , …. are not dominated by defini+ons d 1 , d 2 , d 3 , … § direct predecessors of n 1 , n 2 , … are dominated § At least one direct predecessor is dominated § n 1 , n 2 , … on a path from d 1 , d 2 , … to u § These nodes form the dominance fron0er § Note: u may be n 1 , n 2 , … 50

3.3 Dominance fronKer § The dominance fronKer gives us the earliest place to insert a φ funcKon. § How do we compute the dominance fronKer (DF)? 51