Lecture 15 – Dataflow Analysis Eran Yahav 1 www.cs.technion.ac.il/~yahave/tocs2011/compilers-lec15.pptx.

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

Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis – today’s class –Classic analyses.
1 CS 201 Compiler Construction Lecture 3 Data Flow Analysis.
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis – today’s class –Classic analyses.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) Dataflow Analysis Introduction Guo, Yao Part of the slides are adapted from.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
1 Data flow analysis Goal : collect information about how a procedure manipulates its data This information is used in various optimizations For example,
Lecture 02 – Structural Operational Semantics (SOS) Eran Yahav 1.
Lecture 16 – Dataflow Analysis Eran Yahav 1 Reference: Dragon 9, 12.
Lecture 03 – Background + intro AI + dataflow and connection to AI Eran Yahav 1.
Lecture 04 – Numerical Abstractions Eran Yahav 1.
Foundations of Data-Flow Analysis. Basic Questions Under what circumstances is the iterative algorithm used in the data-flow analysis correct? How precise.
1 Basic abstract interpretation theory. 2 The general idea §a semantics l any definition style, from a denotational definition to a detailed interpreter.
Common Sub-expression Elim Want to compute when an expression is available in a var Domain:
1 Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications.
1 Data flow analysis Goal : –collect information about how a procedure manipulates its data This information is used in various optimizations –For example,
CS 536 Spring Global Optimizations Lecture 23.
From last time: live variables Set D = 2 Vars Lattice: (D, v, ?, >, t, u ) = (2 Vars, µ, ;,Vars, [, Å ) x := y op z in out F x := y op z (out) = out –
Chair of Software Engineering Fundamentals of Program Analysis Dr. Manuel Oriol.
Data Flow Analysis Compiler Design Nov. 3, 2005.
4/25/08Prof. Hilfinger CS164 Lecture 371 Global Optimization Lecture 37 (From notes by R. Bodik & G. Necula)
Programming Language Semantics Mooly SagivEran Yahav Schrirber 317Open space html://
1 CS 201 Compiler Construction Lecture 3 Data Flow Analysis.
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.
Data Flow Analysis Compiler Design Nov. 8, 2005.
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs, Data-flow Analysis Data-flow Frameworks --- today’s.
Prof. Fateman CS 164 Lecture 221 Global Optimization Lecture 22.
Direction of analysis Although constraints are not directional, flow functions are All flow functions we have seen so far are in the forward direction.
U NIVERSITY OF M ASSACHUSETTS, A MHERST D EPARTMENT OF C OMPUTER S CIENCE Advanced Compilers CMPSCI 710 Spring 2003 Data flow analysis Emery Berger University.
From last lecture We want to find a fixed point of F, that is to say a map m such that m = F(m) Define ?, which is ? lifted to be a map: ? = e. ? Compute.
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.
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis: Data-flow frameworks –Classic.
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Abstract Interpretation (Cousot, Cousot 1977) also known as Data-Flow Analysis.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
Example x := read() v := a + b x := x + 1 w := x + 1 a := w v := a + b z := x + 1 t := a + b.
MIT Foundations of Dataflow Analysis Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology.
MIT Introduction to Program Analysis and Optimization Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology.
Jeffrey D. Ullman Stanford University. 2 boolean x = true; while (x) {... // no change to x }  Doesn’t terminate.  Proof: only assignment to x is at.
Compiler Principles Fall Compiler Principles Lecture 0: Local Optimizations Roman Manevich Ben-Gurion University.
Eran Yahav 1. Previously…  An algorithmic view  Abstract data types (ADT)  Correctness Conditions  Sequential consistency  Linearizability  Treiber’s.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
1 Data Flow Analysis Data flow analysis is used to collect information about the flow of data values across basic blocks. Dominator analysis collected.
Lecture 13 – Dataflow Analysis (and more!) Eran Yahav 1 Reference: Dragon 9, 12.
Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications Chapter.
1 Iterative Program Analysis Abstract Interpretation Mooly Sagiv Tel Aviv University Textbook:
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis: Data-flow frameworks –Classic.
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Data Flow Analysis II AModel Checking and Abstract Interpretation Feb. 2, 2011.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Iterative Dataflow Problems Taken largely from notes of Alex Aiken (UC Berkeley) and Martin Rinard (MIT) Dataflow information used in optimization Several.
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 8: Static Analysis II Roman Manevich Ben-Gurion University.
Dataflow Analysis CS What I s Dataflow Analysis? Static analysis reasoning about flow of data in program Different kinds of data: constants, variables,
Code Optimization Data Flow Analysis. Data Flow Analysis (DFA)  General framework  Can be used for various optimization goals  Some terms  Basic block.
Textbook: Principles of Program Analysis
Iterative Dataflow Problems
Dataflow analysis.
G. Ramalingam Microsoft Research, India & K. V. Raghavan
Another example: constant prop
1. Reaching Definitions Definition d of variable v: a statement d that assigns a value to v. Use of variable v: reference to value of v in an expression.
Data Flow Analysis Compiler Design
Live variables and copy propagation
Presentation transcript:

Lecture 15 – Dataflow Analysis Eran Yahav 1

Static Analysis Reason statically (at compile time) about the possible runtime behaviors of a program “The algorithmic discovery of properties of a program by inspection of its source text 1 ” -- Manna, Pnueli 1 Does not have to literally be the source text, just means w/o running it 2

Static Analysis x = ? if (x > 0) { y = 42; } else { y = 73; foo(); } assert (y == 42);  Bad news: problem is generally undecidable 3

universe Static Analysis  Central idea: use approximation Under Approximation Exact set of configurations/ behaviors Over Approximation 4

x = ? if (x > 0) { y = 42; } else { y = 73; foo(); } assert (y == 42);  Over approximation: assertion may be violated 5

 Lose precision only when required  Understand where precision is lost Precision main(…) { printf(“assertion may be vioalted\n”); } 6

Static Analysis  Formalize software behavior in a mathematical model (semantics)  Prove properties of the mathematical model  Automatically, typically with approximation of the formal semantics  Develop theory and tools for program correctness and robustness 7

Static Analysis  Spans a wide range from type checking to full verification  General safety specifications  Security properties (e.g., information flow)  Concurrency correctness conditions (e.g., progress, linearizability)  Correct use of libraries (e.g., typestate)  Under-approximations useful for bug-finding, test-case generation,… 8

Static Analysis: Techniques  Dataflow analysis  Constraint-based analysis  Type and effect systems  Abstract Interpretation (advanced course next semester)  … 9

The WHILE Language: Syntax A  AExp arithmetic expressions B  BExp boolean expressions S  Stmt statements Var set of variables Lab set of labels Op a arithmetic operators Op b boolean operators Op r relational operators a ::= x | n | a1 op a a2 b ::= true | false | not b | b1 op b b2 | a1 op r a2 S ::= [x := a] lab | [skip] lab | S1;S2 | if [b] lab then S1 else S2 | while [b] lab do S (We are going to abuse syntax later for readability) 10

A: AExp  (State  Z) A  x  =  (x) A  n  = N  n  A  a1 op a2  = A  a1  op A  a2  B: BExp  (State  { true, false} ) B  not b  =  B  b  B  b1 op b b2  = B  b1  op b B  b2  B  a1 op r a2  = A  a1  op r A  a2    State = Var  Z The WHILE Language: Structural Operational Semantics Configuration: or just  for terminal configuration 11

The WHILE Language: Structural Operational Semantics (Table 2.6 from PPA) [seq 1 ]  [seq 2 ]   ’    [x  A  a  ][ass]   [skip]  if B  b   = true [if 1 ]  if B  b   = false [if 2 ]  if B  b   = true [wh 1 ]   if B  b   = false [wh 1 ] 12

Example of Derivation Sequence [y := x] 1 ; [z := 1] 2 ; while [y > 0] 3 ( [z := z * y] 4 ; [y := y − 1] 5 ; ) [y := 0] 6 0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  0, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  0 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 } >  0] 3 ([z := z * y] 4 ;[y := y − 1] 5 ;)[y := 0] 6,{ x  42, y  42, z  1 }> … 13

Dataflow Analysis  Reaching Definitions  The assignment lab: var := exp reaches lab’ if there is an execution where var was last assigned at lab 1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y − 1 } 6: y := 0 (adapted from Nielson, Nielson & Hankin) { (x,?), (y,?), (z,?) } { (x,?), (y,1), (z,?) } { (x,?), (y,1), (z,2) } { (x,?), (y,?), (z,4) } { (x,?), (y,5), (z,4) } { (x,?), (y,1), (z,2) } { (x,?), (y,?), (z,?) } { (x,?), (y,1), (z,2) } 14

Dataflow Analysis  Reaching Definitions  The assignment lab: var := exp reaches lab’ if there is an execution where var was last assigned at lab 1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y − 1 } 6: y := 0 (adapted from Nielson, Nielson & Hankin) { (x,?), (y,?), (z,?) } { (x,?), (y,1), (z,?) } { (x,?), (y,1), (z,2), (y,5), (z,4) } { (x,?), (y,?), (z,4), (y,5) } { (x,?), (y,5), (z,4) } { (x,?), (y,1), (z,2), (y,5), (z,4) } { (x,?), (y,6), (z,2), (z,4) } { (x,?), (y,1), (z,2), (y,5), (z,4) } 15

Dataflow Analysis  Build control-flow graph  Assign transfer functions  Compute fixed point 16

Control-Flow Graph 1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y − 1 } 6: y := 0 1: y:=x 2: z:=1 3: y > 0 4: z=z*y 5: y=y-1 6: y:=0 17

Transfer Functions 1: y:=x 2: z:=1 3: y > 0 4: z=z*y 5: y=y-1 6: y:=0 out(1) = in(1) \ { (y,l) | l  Lab } U { (y,1) } out(2) = in(2) \ { (z,l) | l  Lab } U { (z,2) } in(1) = { (x,?), (y,?), (z,?) } in(2) = out(1) in(3) = out(2) U out(5) in(4) = out(3) in(5) = out(4) in(6) = out(3) out(4) = in(4) \ { (z,l) | l  Lab } U { (z,4) } out(5) = in(5) \ { (y,l) | l  Lab } U { (y,5) } out(6) = in(6) \ { (y,l) | l  Lab } U { (y,6) } out(3) = in(3) 18

System of Equations in(1) = { (x,?), (y,?), (z,?) } in(2) = out(1) in(3) = out(2) U out(5) in(4) = out(3) in(5) = out(4) In(6) = out(3) out(1) = in(1) \ { (y,l) | l  Lab } U { (y,1) } out(2) = in(2) \ { (z,l) | l  Lab } U { (z,2) } out(3) = in(3) out(4) = in(4) \ { (z,l) | l  Lab } U { (z,4) } out(5) = in(5) \ { (y,l) | l  Lab } U { (y,5) } out(6) = in(6) \ { (y,l) | l  Lab } U { (y,6) } F: (  (Var x Lab) ) 12  (  (Var x Lab) ) 12 19

System of Equations in(1) = { (x,?), (y,?), (z,?) } in(2) = out(1) in(3) = out(2) U out(5) in(4) = out(3) in(5) = out(4) In(6) = out(3) out(1) = in(1) \ { (y,l) | l  Lab } U { (y,1) } out(2) = in(2) \ { (z,l) | l  Lab } U { (z,2) } out(3) = in(3) out(4) = in(4) \ { (z,l) | l  Lab } U { (z,4) } out(5) = in(5) \ { (y,l) | l  Lab } U { (y,5) } out(6) = in(6) \ { (y,l) | l  Lab } U { (y,6) } F: (  (Var x Lab) ) 12  (  (Var x Lab) ) 12 in(1)={(x,?),(y,?),(z,?)}, in(2)=out(1), in(3)=out(2) U out(5), in(4)=out(3), in(5)=out(4),In(6) = out(3) out(1) = in(1) \ { (y,l) | l  Lab } U { (y,1) }, out(2) = in(2) \ { (z,l) | l  Lab } U { (z,2) } out(3) = in(3), out(4) = in(4) \ { (z,l) | l  Lab } U { (z,4) } out(5) = in(5) \ { (y,l) | l  Lab } U { (y,5) }, out(6) = in(6) \ { (y,l) | l  Lab } U { (y,6) } In(1)  {(x,?),(y,?),(z,?)}== In(2)  {(y,1)}{(x,?),(y,1),(z,?)}== In(3)  {(z,2),(y,5)} {(z,2),(z,4),(y,5)} In(4)  {(z,2),(y,5)} In(5)  {(z,4)} In(6)  {(z,2),(y,5)} Out(1)  {(y,1)}{(x,?),(y,1),(z,?)}== Out(2)  {(z,2)} {(z,2),(y,1)}== Out(3)  {(z,2),(y,5)} Out(4)  {(z,4)} Out(5)  {(y,5)} {(z,4),(y,5)} Out(6)  {(y,6)} … 20

F: (  (Var x Lab) ) 12  (  (Var x Lab) ) 12 RD  RD’ when  i: RD(i)  RD’(i) … RD  F(RD  )F(F(RD  ))F(F(F(RD  )))F(F(F(F(RD  )))) In(1)  {(x,?),(y,?),(z,?)}== In(2)  {(y,1)}{(x,?),(y,1),(z,?)}== In(3)  {(z,2),(y,5)} {(z,2),(z,4),(y,5)} In(4)  {(z,2),(y,5)} In(5)  {(z,4)} In(6)  {(z,2),(y,5)} Out(1)  {(y,1)}{(x,?),(y,1),(z,?)}== Out(2)  {(z,2)} {(z,2),(y,1)}== Out(3)  {(z,2),(y,5)} Out(4)  {(z,4)} Out(5)  {(y,5)} {(z,4),(y,5)} Out(6)  {(y,6)} System of Equations 21

Monotonicity F: (  (Var x Lab) ) 12  (  (Var x Lab) ) 12 RD  F(RD  )F(F(RD  ))F(F(F(RD  )))F(F(F(F(RD  )))) … Out(1)  {(y,1)}{(x,?),(y,1),(z,?)}{(y,1)}…. … … out(1) = {(y,1)} when (x,?)  out(1) in(1) \ { (y,l) | l  Lab } U { (y,1) }, otherwise (silly example just for illustration) 22

Convergence 0 1 … 2 n 0 1 … 2 n 0 1 … 2 23

Least Fixed Point  We will see later why it exists  For now, mostly informally… F: (  (Var x Lab) ) 12  (  (Var x Lab) ) 12 RD  RD’ when  i: RD(i)  RD’(i) F is monotone: RD  RD’ implies that F(RD)  F(RD’) RD  = ( , ,…,  ) F(RD  ), F(F(RD  ), F(F(F(RD  )), … F n (RD  ) F n+1 (RD  ) = F n (RD  ) RD  F(RD  )   F(F(RD  )) …  F n (RD  ) 24

Things that Should Trouble You  How did we get the transfer functions?  How do we know these transfer functions are safe (conservative)?  How do we know that these transfer functions are optimal? 25

Some required notation 26 blocks : Stmt  P(Blocks) blocks([x := a] lab ) = {[x := a] lab } blocks([skip] lab ) = {[skip] lab } blocks(S1; S2) = blocks(S1)  blocks(S2) blocks(if [b] lab then S1 else S2) = {[b] lab }  blocks(S1)  blocks(S2) blocks(while [b] lab do S) = {[b] lab }  blocks(S) FV: (BExp  AExp)  Var Variables used in an expression AExp(a) = all non-unit expressions in the arithmetic expression a similarly AExp(b) for a boolean expression b

Available Expressions Analysis 27 For each program point, which expressions must have already been computed, and not later modified, on all paths to the program point [x := a+b] 1 ; [y := a*b] 2 ; while [y > a+b] 3 ( [a := a + 1] 4 ; [x := a + b] 5 ) (a+b) always available at label 3

Available Expressions Analysis  Property space  in AE, out AE : Lab   (AExp)  Mapping a label to set of arithmetic expressions available at that label  Dataflow equations  Flow equations – how to join incoming dataflow facts  Effect equations - given an input set of expressions S, what is the effect of a statement 28

 in AE (lab) =   when lab is the initial label   { out AE (lab’) | lab’  pred(lab) } otherwise  out AE (lab) = … 29 Blockout (lab) [x := a] lab in(lab) \ { a’  AExp | x  FV(a’) } U { a’  AExp(a) | x  FV(a’) } [skip] lab in(lab) [b] lab in(lab) U AExp(b) Available Expressions Analysis From now on going to drop the AE subscript when clear from context

Transfer Functions 1: x = a+b 2: y:=a*b 3: y > a+b 4: a=a+1 5: x=a+b out(1) = in(1) U { a+b } out(2) = in(2) U { a*b } in(1) =  in(2) = out(1) in(3) = out(2)  out(5) in(4) = out(3) in(5) = out(4) out(4) = in(4) \ { a+b,a*b,a+1 } out(5) = in(5) U { a+b } out(3) = in(3) U { a+ b } 30 [x := a+b] 1 ; [y := a*b] 2 ; while [y > a+b] 3 ( [a := a + 1] 4 ; [x := a + b] 5 )

Solution 1: x = a+b 2: y:=a*b 3: y > a+b 4: a=a+1 5: x=a+b in(2) = out(1) = { a + b } out(2) = { a+b, a*b } out(4) =  out(5) = { a+b } in(4) = out(3) = { a+ b } 31 in(1) =  in(3) = { a + b }

Kill/Gen 32 Blockout (lab) [x := a] lab in(lab) \ { a’  AExp | x  FV(a’) } U { a’  AExp(a) | x  FV(a’) } [skip] lab in(lab) [b] lab in(lab) U AExp(b) Blockkillgen [x := a] lab { a’  AExp | x  FV(a’) } { a’  AExp(a) | x  FV(a’) } [skip] lab  [b] lab  AExp(b) out(lab) = in(lab) \ kill(B lab ) U gen(B lab ) B lab = block at label lab

Why solution with largest sets? 33 1: z = x+y 2: true 3: skip out(1) = in(1) U { x+y } in(1) =  in(2) = out(1)  out(3) in(3) = out(2) out(3) = in(3) out(2) = in(2) [z := x+y] 1 ; while [true] 2 ( [skip] 3 ; ) in(1) =  After simplification: in(2) = in(2)  { x+y } Solutions: {x+y} or  in(2) = out(1)  out(3) in(3) = out(2)

Reaching Definitions Revisited 34 Blockout (lab) [x := a] lab in(lab) \ { (x,l) | l  Lab } U { (x,lab) } [skip] lab in(lab) [b] lab in(lab) Blockkillgen [x := a] lab { (x,l) | l  Lab }{ (x,lab) } [skip] lab  [b] lab  For each program point, which assignments may have been made and not overwritten, when program execution reaches this point along some path.

Why solution with smallest sets? 35 1: z = x+y 2: true 3: skip out(1) = ( in(1) \ { (z,?) } ) U { (z,1) } in(1) = { (x,?),(y,?),(z,?) } in(2) = out(1) U out(3) in(3) = out(2) out(3) = in(3) out(2) = in(2) [z := x+y] 1 ; while [true] 2 ( [skip] 3 ; ) in(1) = { (x,?),(y,?),(z,?) } After simplification: in(2) = in(2) U { (x,?),(y,?),(z,1) } Many solutions: any superset of { (x,?),(y,?),(z,1) } in(2) = out(1) U out(3) in(3) = out(2)

Live Variables 36 For each program point, which variables may be live at the exit from the point. [ x :=2] 1 ; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7

[ x :=2] 1 ; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7 Live Variables 1: x := 2 2: y:=4 4: y > x 5: z := y 7: x := z 6: z = y*y 3: x:=1

1: x := 2 2: y:=4 4: y > x 5: z := y 7: x := z 38 [ x :=2] 1 ; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7 6: z = y*y Live Variables Blockkillgen [x := a] lab { x }{ FV(a) } [skip] lab  [b] lab  FV(b) 3: x:=1

1: x := 2 2: y:=4 4: y > x 5: z := y 7: x := z 39 [ x :=2] 1 ; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7 6: z = y*y Live Variables: solution Blockkillgen [x := a] lab { x }{ FV(a) } [skip] lab  [b] lab  FV(b) 3: x:=1 in(1) =  out(1) = in(2) =  out(2) = in(3) = { y } out(3) = in(4) = { x,y } in(7) = { z } out(7) =  out(6) = { z } in(6) = { y } out(5) = { z } in(5) = { y } in(4) = { x,y } out(4) = { y }

Why solution with smallest set? 40 1: x>1 2: skip out(1) = in(2) U in(3) out(2) = in(1) out(3) =  in(2) = out(2) while [x>1] 1 ( [skip] 2 ; ) [x := x+1] 3 ; After simplification: in(1) = in(1) U { x } Many solutions: any superset of { x } 3: x := x + 1 in(3) = { x } in(1) = out(1)  { x }

Monotone Frameworks   is  or   CFG edges go either forward or backwards  Entry labels are either initial program labels or final program labels (when going backwards)  Initial is an initial state (or final when going backwards)  f lab is the transfer function associated with the blocks B lab 41 In(lab) =  { out(lab’) | (lab’,lab)  CFG edges } Initialwhen lab  Entry labels otherwise out(lab) = f lab (in(lab))

Forward vs. Backward Analyses 42 1: x := 2 2: y:=4 4: y > x 5: z := y 7: x := z 6: z = y*y 1: x := 2 2: y:=4 4: y > x 5: z := y 7: x := z 6: z = y*y {(x,1), (y,?), (z,?) } { (x,?), (y,?), (z,?) } {(x,1), (y,2), (z,?) }  { z } { y }

Must vs. May Analyses  When  is  - must analysis  Want largest sets the solves the equation system  Properties hold on all paths reaching a label (exiting a label, for backwards)  When  is  - may analysis  Want smallest sets that solve the equation system  Properties hold at least on one path reaching a label (existing a label, for backwards) 43

Example: Reaching Definition  L =  (Var×Lab) is partially ordered by    is   L satisfies the Ascending Chain Condition because Var × Lab is finite (for a given program) 44

Example: Available Expressions  L =  (AExp) is partially ordered by    is   L satisfies the Ascending Chain Condition because AExp is finite (for a given program) 45

Analyses Summary 46 Reaching Definitions Available Expressions Live Variables L  (Var x Lab)  (AExp)  (Var)    AExp  Initial{ (x,?) | x  Var}  Entry labels{ init } final DirectionForward Backward F{ f: L  L |  k,g : f(val) = (val \ k) U g } f lab f lab (val) = (val \ kill)  gen

Analyses as Monotone Frameworks  Property space  Powerset  Clearly a complete lattice  Transformers  Kill/gen form  Monotone functions (let’s show it) 47

Monotonicity of Kill/Gen transformers  Have to show that x  x’ implies f(x)  f(x’)  Assume x  x’, then for kill set k and gen set g (x \ k) U g  (x’ \ k) U g  Technically, since we want to show it for all functions in F, we also have to show that the set is closed under function composition 48

Distributivity of Kill/Gen transformers  Have to show that f(x  y)  f(x)  f(y)  f(x  y) = ((x  y) \ k) U g = ((x \ k)  (y \ k)) U g = (((x \ k) U g)  ((y \ k) U g)) = f(x)  f(y)  Used distributivity of  and U  Works regardless of whether  is U or  49