Liveness Analysis Mooly Sagiv Schrierber 317 03-640-7606 Wed 10:00-12:00 html://www.math.tau.ac.il/~msagiv/courses/wcc02.html.

Slides:



Advertisements
Similar presentations
Data-Flow Analysis II CS 671 March 13, CS 671 – Spring Data-Flow Analysis Gather conservative, approximate information about what a program.
Advertisements

P3 / 2004 Register Allocation. Kostis Sagonas 2 Spring 2004 Outline What is register allocation Webs Interference Graphs Graph coloring Spilling Live-Range.
Lecture 11: Code Optimization CS 540 George Mason University.
Register Allocation CS 320 David Walker (with thanks to Andrew Myers for most of the content of these slides)
Compilation 2011 Static Analysis Johnni Winther Michael I. Schwartzbach Aarhus University.
Register Allocation Mooly Sagiv Schrierber Wed 10:00-12:00 html://
COMPILERS Register Allocation hussein suleman uct csc305w 2004.
1 CS 201 Compiler Construction Machine Code Generation.
Control-Flow Graphs & Dataflow Analysis CS153: Compilers Greg Morrisett.
CS412/413 Introduction to Compilers Radu Rugina Lecture 37: DU Chains and SSA Form 29 Apr 02.
Stanford University CS243 Winter 2006 Wei Li 1 Register Allocation.
Register Allocation CS 671 March 27, CS 671 – Spring Register Allocation - Motivation Consider adding two numbers together: Advantages: Fewer.
Components of representation Control dependencies: sequencing of operations –evaluation of if & then –side-effects of statements occur in right order Data.
Program Representations. Representing programs Goals.
Common Sub-expression Elim Want to compute when an expression is available in a var Domain:
Basic Blocks Mooly Sagiv Schrierber Wed 10:00-12:00 html:// Chapter 8.
1 CS 201 Compiler Construction Lecture 12 Global Register Allocation.
Register Allocation Mooly Sagiv html://
Representing programs Goals. Representing programs Primary goals –analysis is easy and effective just a few cases to handle directly link related things.
1 Handling nested procedures Method 1 : static (access) links –Reference to the frame of the lexically enclosing procedure –Static chains of such links.
Cpeg421-08S/final-review1 Course Review Tom St. John.
Program analysis Mooly Sagiv html://
Improving code generation. Better code generation requires greater context Over expressions: optimal ordering of subtrees Over basic blocks: Common subexpression.
Code Generation Professor Yihjia Tsai Tamkang University.
Register Allocation Mooly Sagiv Make-Up Class Optional Material Friday 10:00-13:00 Schriber 6 html://
Code Generation Simple Register Allocation Mooly Sagiv html:// Chapter
Program analysis Mooly Sagiv html://
Code Generation for Basic Blocks Introduction Mooly Sagiv html:// Chapter
Register Allocation (via graph coloring)
Data Flow Analysis Compiler Design October 5, 2004 These slides live on the Web. I obtained them from Jeff Foster and he said that he obtained.
Abstract Interpretation Part I Mooly Sagiv Textbook: Chapter 4.
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Code Generation Mooly Sagiv html:// Chapter 4.
Register Allocation Mooly Sagiv html://
Register Allocation (via graph coloring). Lecture Outline Memory Hierarchy Management Register Allocation –Register interference graph –Graph coloring.
Overview of program analysis Mooly Sagiv html://
1 Liveness analysis and Register Allocation Cheng-Chia Chen.
Improving Code Generation Honors Compilers April 16 th 2002.
Recap from last time: live variables x := 5 y := x + 2 x := x + 1 y := x y...
Improving code generation. Better code generation requires greater context Over expressions: optimal ordering of subtrees Over basic blocks: Common subexpression.
Register Allocation Recap Mooly Sagiv html:// Special Office Hours Wednesday 12-14, Thursday 12-14, Schriber.
Direction of analysis Although constraints are not directional, flow functions are All flow functions we have seen so far are in the forward direction.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Overview of program analysis Mooly Sagiv html://
Code Generation Mooly Sagiv html:// Chapter 4.
Register Allocation Mooly Sagiv html://
Precision Going back to constant prop, in what cases would we lose precision?
Data Flow Analysis Compiler Baojian Hua
1 Iterative Program Analysis Abstract Interpretation Mooly Sagiv Tel Aviv University Textbook:
Dataflow Analysis Topic today Data flow analysis: Section 3 of Representation and Analysis Paper (Section 3) NOTE we finished through slide 30 on Friday.
Interference Graphs for Programs in Static Single Information Form are Interval Graphs Philip Brisk Processor Architecture Laboratory (LAP) EPFL Lausanne,
Compiler Principles Fall Compiler Principles Lecture 0: Local Optimizations Roman Manevich Ben-Gurion University.
Intermediate Code Representations
1 Iterative Program Analysis Abstract Interpretation Mooly Sagiv Tel Aviv University Textbook:
1 Numeric Abstract Domains Mooly Sagiv Tel Aviv University Adapted from Antoine Mine.
1 Liveness analysis and Register Allocation Cheng-Chia Chen.
COMPILERS Liveness Analysis hussein suleman uct csc3003s 2009.
Data Flow Analysis Suman Jana
Mooly Sagiv html://
Register Allocation Noam Rinetzky Text book:
Compilation /17a Lecture 10
Topic 10: Dataflow Analysis
University Of Virginia
CS 201 Compiler Construction
Data Flow Analysis Compiler Design
Compiler Construction
Code Generation Part II
COMPILERS Liveness Analysis
CSE P 501 – Compilers SSA Hal Perkins Autumn /31/2019
CS 201 Compiler Construction
Presentation transcript:

Liveness Analysis Mooly Sagiv Schrierber Wed 10:00-12:00 html://

Basic Compiler Phases Source program (string) Fin. Assembly lexical analysis syntax analysis semantic analysis Translate Instruction selection Register Allocation Tokens Abstract syntax tree Intermediate representation Assembly Frame

Register Allocation Input: –Sequence of machine code instructions (assembly) Unbounded number of temporary registers Output –Sequence of machine code instructions (assembly) –Machine registers –Some MOVE instructions removed –Missing prologue and epilogue

LABEL(l3) CJUMP(EQ, TEMP t128, CONST 0, l0, l1) LABEL( l1) MOVE(TEMP t131, TEMP t128) MOVE(TEMP t130, CALL(nfactor, BINOP(MINUS, TEMP t128, CONST 1))) MOVE(TEMP t129, BINOP(TIMES, TEMP t131, TEMP t130)) LABEL(l2) MOVE(TEMP t103, TEMP t129) JUMP(NAME lend) LABEL(l0) MOVE(TEMP t129, CONST 1) JUMP(NAME l2) Missing updates for static link

l3:beq t128, $0, l0 l1: or t131, $0, t128 addi t132, t128, -1 or $4, $0, t132 jal nfactor or t130, $0, $2 or t133, $0, t131 mult t133, t130 mflo t133 or t129, $0, t133 l2: or t103, $0, t129 b lend l0: addi t129, $0, 1 b l2 l3:beq $25, $0, l0 l1: or $30, $0, $25 addi $4, $25, -1 /*or $4, $0, $4 */ jal nfactor /*or $2, $0, $2 */ /*or $30, $0, $30 */ mult $30, $2 mflo $30 /*or $30, $0, $30 */ l2: or $2, $0, $30 b lend l0: addi $30, $0, 1 b l2 t128$25 t129$30 t130$2 t131$30 t132$4 t133$30 t103$2

.globalnfactor.entnfactor factor_framesize=40.frame$sp,nfactor_framesize,$31 nfactor: addiu$sp,$sp,-nfactor_framesize sw$2,0+nfactor_framesize($sp) or$25, $0, $4 sw$31,-4+nfactor_framesize($sp) sw$30,-8+nfactor_framesize($sp) lend:lw$30,-8+nfactor_framesize($sp) lw$31,-4+nfactor_framesize($sp) addiu$sp,$sp,nfactor_framesize j$31.endnfactor l3:beq $25, $0, l0 l1: or $30, $0, $25 addi $4, $25, -1 jal nfactor mult $30, $2 mflo $30 l2: or $2, $0, $30 b lend l0: addi $30, $0, 1 b l2

The need for “spilling” The number of registers may not be enough –Spill the content of some registers into memory –Load when needed Increase the number of instructions Increase CPU time

The Challenge Minimize the number of spills Minimize the number of MOVEs Minimize CPU time

Outline Liveness Analysis –Motivation –Static Liveness –Dataflow Equations –Solutions –An Iterative Algorithm –Liveness in Tiger (Targil) Actual Allocation –Next week

Liveness Analysis The same register may be assigned (at compile-time) to two temporaries if their “life-times” do not overlap A variable is live a given program point –its current is used after this point prior to a definition (assignment) v is live at a given program point There exists an execution sequence from this point to a use of v that does not assign to v Two variables interfere at a given point –they are simultaneously live at this point

A Simple Example /* c */ L0: a := 0 /* ac */ L1:b := a + 1 /* bc */ c := c + b /* bc */ a := b * 2 /* ac */ if c < N goto L1 /* c */ return c ab c

Liveness Interference Graph For every compiled function Nodes –Pre-colored machine registers –Temporaries Undirected-Edges –Temporaries that are simultaneously alive –Different machine registers Undirected MOVE edges –“Correlated” temporaries and registers

Other usages of Livness

A Simple Example /* c */ L0: a := 0 /* ac */ L1:b := a + 1 /* bc */ c := c + b /* bc */ a := b * 2 /* ac */ if c < N goto L1 /* c */ return c ab c

l3:beq t128, $0, l0 /* $0, t128 */ l1: or t131, $0, t128 /* $0, t128, t131 */ addi t132, t128, -1 /* $0, t131, t132 */ or $4, $0, t132 /* $0, $4, t131 */ jal nfactor /* $0, $2, t131 */ or t130, $0, $2 /* $0, t130, t131 */ or t133, $0, t131 /* $0, t130, t133 */ mult t133, t130 /* $0, t133 */ mflo t133 /* $0, t133 */ or t129, $0, t133 /* $0, t129 */ l2: or t103, $0, t129 /* $0, t103 */ b lend /* $0, t103 */ l0: addi t129, $0, 1 /* $0, t129 */ b l2 /* $0, t129 */ t133 $2 $0 $4 t128 t129 t130 t131 t132 t103

Undecidabily A variable is live at a given point in the program –if its current value is used after this point prior to a definition in some execution path It is undecidable if a variable is live at a given program location

Proof Sketch Pr L: x := y Is y live at L?

Conservative The compiler need not generate the optimal code Can use more registers (“spill code”) than necessary Find an upper approximation of the live variables A superset of edges in the interference graph Not too many superfluous live variables

Control Flow Graph Nodes –Assembly instructions Directed-Edges – If an instruction x can be immediately followed by an instruction y A directed edge x  y

Static Liveness A variable v is statically live at control flow node n –there exists a directed path p from n to a use of v such that p does not include an assignment to v Every live variable is statically live Some statically live variables are not live –since some control flow paths are non- executable

Example a := b * b ; c := a + b ; if (c >= b) then return c; else return a; a := b * b ; c := a + b ; c >= b return c; return a;

/* c */ L0: a := 0 /* ac */ L1:b := a + 1 /* bc */ c := c + b /* bc */ a := b * 2 /* ac */ if c < N goto L1 /* c */ return c a := 0 ; b := a +1 ; c := c +b ; a := b*2 ; c <N goto L1 return c ;

Computing Static Liveness Generate a system of equations for every function –define the set of live variables recursively Iteratively compute a minimal solution

The System of Equations For every instruction n –def[n] The temporary and physical register(s) assigned by n –use[n] The temporary and physical register used in n System of equations –LiveOut[ex] =  –LiveOut[n] =  (n, m)  Edges Live[m] –Live[n] = (LiveOut[n] – def[n])  use[n]

a := 0 ; b := a +1 ; c := c +b ; a := b*2 ; c <N goto L1 return c ; insdef[n]use[n] 1{a}  2{b}{a} 3{c}{c, b} 4{a}{b} 5  {c} 6  LiveOut[6] =  Live[6] = (LiveOut[6] –  )  {c} LiveOut[5] = Live[6]  Live[2] Live[5] = (LiveOut[5] –  )  {c} LiveOut[4] = Live[5] Live[4] = (LiveOut[4] – {a})  {b} LiveOut[3] = Live[4]Live[3] = (LiveOut[3] – {c})  {c, b} LiveOut[2] = Live[3]Live[2] = (LiveOut[2] – {b})  {a} LiveOut[1] = Live[2] Live[1] = (LiveOut[1] – {a})  

a := 0 ; b := a +1 ; c := c +b ; a := b*2 ; c <N goto L1 return c ; insdef[n]use[n] 1{a}  2{b}{a} 3{c}{c, b} 4{a}{b} 5  {c} 6  LiveOut[6] =  Live[6] = LiveOut[6]  {c} LiveOut[5] = Live[6]  Live[2] Live[5] = LiveOut[5]  {c} LiveOut[4] = Live[5] Live[4] = (LiveOut[4] – {a})  {b} LiveOut[3] = Live[4]Live[3] = (LiveOut[3] – {c})  {c, b} LiveOut[2] = Live[3]Live[2] = (LiveOut[2] – {b})  {a} LiveOut[1] = Live[2] Live[1] = (LiveOut[1] – {a})

Fixed Points A fixed point is a vector solution Live and LiveOut –for every instruction n LiveOut[ex] =  LiveOut[n] =  (n, m)  Edges Live[m] Live[n] = (LiveOut[n] – def[n])  use[n] There more than one fixed point Every fixed point contains at least the statically live variables The least fixed point (in terms of set inclusion) uniquely exists –it contains exactly the statically live variables

a := 0 ; b := a +1 ; c := c +b ; a := b*2 ; c <N goto L1 return c ; LiveOut[6] =  Live[6] = LiveOut[6]  {c} LiveOut[5] = Live[6]  Live[2] Live[5] = LiveOut[5]  {c} LiveOut[4] = Live[5] Live[4] = (LiveOut[4] – {a})  {b} LiveOut[3] = Live[4]Live[3] = (LiveOut[3] – {c})  {c, b} LiveOut[2] = Live[3]Live[2] = (LiveOut[2] – {b})  {a} LiveOut[1] = Live[2] Live[1] = (LiveOut[1] – {a}) insLiveOutLive 1{c, a}{c} 2{c, b}{c, a} 3{c, b} 4{c, a}{c, b} 5{c,a} 6  {c}

a := 0 ; b := a +1 ; c := c +b ; a := b*2 ; c <N goto L1 return c ; LiveOut[6] =  Live[6] = LiveOut[6]  {c} LiveOut[5] = Live[6]  Live[2] Live[5] = LiveOut[5]  {c} LiveOut[4] = Live[5] Live[4] = (LiveOut[4] – {a})  {b} LiveOut[3] = Live[4]Live[3] = (LiveOut[3] – {c})  {c, b} LiveOut[2] = Live[3]Live[2] = (LiveOut[2] – {b})  {a} LiveOut[1] = Live[2] Live[1] = (LiveOut[1] – {a}) insLiveOutLive 1{c, a, d}{c, d} 2{c, b, d}{c, a, d} 3{c, b, d} 4{c, a, d}{c, b, d} 5{c,a, d} 6  {c}

a := 0 ; b := a +1 ; c := c +b ; a := b*2 ; c <N goto L1 return c ; LiveOut[6] =  Live[6] = LiveOut[6]  {c} LiveOut[5] = Live[6]  Live[2] Live[5] = LiveOut[5]  {c} LiveOut[4] = Live[5] Live[4] = (LiveOut[4] – {a})  {b} LiveOut[3] = Live[4]Live[3] = (LiveOut[3] – {c})  {c, b} LiveOut[2] = Live[3]Live[2] = (LiveOut[2] – {b})  {a} LiveOut[1] = Live[2] Live[1] = (LiveOut[1] – {a}) insLiveOutLive 1{c, a, b}{c, b} 2 {c, a} 3{c, b} 4{c, a}{c, b} 5{c, a} 6  {c}

a := 0 ; b := a +1 ; c := c +b ; a := b*2 ; c <N goto L1 return c ; LiveOut[6] =  Live[6] = LiveOut[6]  {c} LiveOut[5] = Live[6]  Live[2] Live[5] = LiveOut[5]  {c} LiveOut[4] = Live[5] Live[4] = (LiveOut[4] – {a})  {b} LiveOut[3] = Live[4]Live[3] = (LiveOut[3] – {c})  {c, b} LiveOut[2] = Live[3]Live[2] = (LiveOut[2] – {b})  {a} LiveOut[1] = Live[2] Live[1] = (LiveOut[1] – {a}) insLiveOutLive 1{c, a}{c} 2{c, b}{c, a} 3{c, b} 4{c}{c, b} 5{c} 6 

Computing Least Fixed Points Start with an empty set of Live and LiveOut for every instruction Repeatedly add new variables according to the equations The sets of LiveOut and Live variables must monotonically increase The process must terminate Unique least solution

WL :=  ; for each instruction n LiveOut[n] :=  Live[n] :=  WL := WL  {n} while WL !=  select and remove n from WL new := (LiveOut[n] –def[n])  use[n] if new != Live[n] then Live[n] := new for all predecessors m of n do LiveOut[m] := LiveOut[m]  Live[n] WL := WL  {m} An Iterative Algorithm

a := 0 ; b := a +1 ; c := c +b ; a := b*2 ; c <N goto L1 return c ; nLive[n]LiveOutWL {6, 5, 4, 3, 2, 1} 6{c}LiveOut[5]={c}{5, 4, 3, 2, 1} 5{c}LiveOut[4]={c}{4, 5, 2, 1} 4{c, b}LiveOut[3]={c,b}{3, 2, 1} 3{c, b}LiveOut[2]={c,b}{2, 1} 2{c, a}LiveOut[1]={c,a} LiveOut[5]={c,a} {5, 1} 5{c, a}LiveOut[4]={c,a}{4, 1} 4{c, b}{1} 1{c} 

Representation of Sets Bit-Vectors –Var bits for every n –Live[n][v] = 1 the variable v is live before n –Cost of set operation is O(Vars/word-size) Ordered Elements –Linear time for set operations

Time Complexity Parameters –N number of nodes (instructions) –Assume that pred[n] is constant –V Number of variables –d Number of loop nesting level DFS back edges Initialization NV Inner-Most Iteration V For-Loop N Repeat –Worst-Case NV –Worst-Case-DFS d + 1 Total-Worst-Case (NV) 2 Total-DFS NVd Single-variable N

for every instruction n for every variable a  def[n] for every variable b  LiveOut[n] Create an interference edge An Interference Graph ba May introduce too many edges for move instructions

t := s … x := … s … … y := t Example

for every non move instruction n for every variable a  def[n] for every variable b  LiveOut[n] Create an interference edge An Interference Graph ba for every move instruction n a:= c for every variable b  LiveOut[n] – {c} Create an interference edge ba

A Simple Example /* c */ L0: a := 0 /* ac */ L1:b := a + 1 /* bc */ c := c + b /* bc */ a := b * 2 /* ac */ if c < N goto L1 /* c */ return c ab c

l3:beq t128, $0, l0 /* $0, t128 */ l1: or t131, $0, t128 /* $0, t128, t131 */ addi t132, t128, -1 /* $0, t131, t132 */ or $4, $0, t132 /* $0, $4, t131 */ jal nfactor /* $0, $2, t131 */ or t130, $0, $2 /* $0, t130, t131 */ or t133, $0, t131 /* $0, t130, t133 */ mult t133, t130 /* $0, t133 */ mflo t133 /* $0, t133 */ or t129, $0, t133 /* $0, t129 */ l2: or t103, $0, t129 /* $0, t103 */ b lend /* $0, t103 */ l0: addi t129, $0, 1 /* $0, t129 */ b l2 /* $0, t129 */ t133 $2 $0 $4 t128 t129 t130 t131 t132 t103

Summary The compiler can statically predict liveness of variables –May be expensive Other useful static information –Constant expressions –Common sub-expression –Loop invariant Liveness inference graph will be colored next week