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)

17

ENTRY A B C D EXIT

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 § ENTRY → A → B → D → EXIT

23

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

Example graph

30

ENTRY

X =

EXIT

X = = X BB6

§ 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 X0, Y0, Z0, … § “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 X0 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

40

X =

B A § No funcKon is needed along path from A to B if A ⨠ B

= X

§ But A = B is possible. Need to deal with § Extend definiKon of dominance from basic blocks (nodes of CFG) to operaKons in basic block

§ defini+ons § uses

42

= X X = X = = X

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

43

¬ (di ⨠ uj)

§ ¬ (di ⨠ uj): di does not dominate uj

44

X =

uj di

= X X =

dk § ∃ at least one path from ENTRY to uj that does not include di (as the last definiKon of X)

Detailed look

§ No φ funcKon if d ⨠ u § φ funcKon if no dominance

45

47

Placement of φ funcKons

§ Look for nodes n1, n2, … that have these properKes

§ n1, n2, …. are not dominated by defini+ons d1, d2, d3, … § direct predecessors of n1, n2, … are dominated

§ At least one direct predecessor is dominated

§ n1, n2, … on a path from d1, d2, … to u

§ These nodes form the dominance fron0er § Note: u may be n1, n2, …

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