Data Flow Analysis II 15-817AModel Checking and Abstract Interpretation Feb. 2, 2011.

Slides:



Advertisements
Similar presentations
Continuing Abstract Interpretation We have seen: 1.How to compile abstract syntax trees into control-flow graphs 2.Lattices, as structures that describe.
Advertisements

Data-Flow Analysis II CS 671 March 13, CS 671 – Spring Data-Flow Analysis Gather conservative, approximate information about what a program.
Lecture 11: Code Optimization CS 540 George Mason University.
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.
(c) 2007 Mauro Pezzè & Michal Young Ch 6, slide 1 Dependence and Data Flow Models.
1 CS 201 Compiler Construction Data Flow Framework.
1 Data flow analysis Goal : collect information about how a procedure manipulates its data This information is used in various optimizations For example,
Foundations of Data-Flow Analysis. Basic Questions Under what circumstances is the iterative algorithm used in the data-flow analysis correct? How precise.
CSE 231 : Advanced Compilers Building Program Analyzers.
Worklist algorithm Initialize all d i to the empty set Store all nodes onto a worklist while worklist is not empty: –remove node n from worklist –apply.
CS 536 Spring Global Optimizations Lecture 23.
Global optimization. Data flow analysis To generate better code, need to examine definitions and uses of variables beyond basic blocks. With use- definition.
From last time: Lattices A lattice is a tuple (S, v, ?, >, t, u ) such that: –(S, v ) is a poset – 8 a 2 S. ? v a – 8 a 2 S. a v > –Every two elements.
Data Flow Analysis Compiler Design Nov. 3, 2005.
From last time: reaching definitions For each use of a variable, determine what assignments could have set the value being read from the variable Information.
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.
CS 412/413 Spring 2007Introduction to Compilers1 Lecture 29: Control Flow Analysis 9 Apr 07 CS412/413 Introduction to Compilers Tim Teitelbaum.
Administrative stuff Office hours: After class on Tuesday.
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.
San Diego October 4-7, 2006 Over 1,000 women in computing Events for undergraduates considering careers and graduate school Events for graduate students.
Recap: Reaching defns algorithm From last time: reaching defns worklist algo We want to avoid using structure of the domain outside of the flow functions.
Prof. Fateman CS 164 Lecture 221 Global Optimization Lecture 22.
1 Data-Flow Frameworks Lattice-Theoretic Formulation Meet-Over-Paths Solution Monotonicity/Distributivity.
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.
1 CS 201 Compiler Construction Lecture 4 Data Flow Framework.
Global optimization. Data flow analysis To generate better code, need to examine definitions and uses of variables beyond basic blocks. With use- definition.
Data Flow Analysis Compiler Design Nov. 8, 2005.
Prof. Aiken CS 294 Lecture 11 Program Analysis. Prof. Aiken CS 294 Lecture 12 The Purpose of this Course How are the following related? –Program analysis.
Claus Brabrand, ITU, Denmark DATA-FLOW ANALYSISMar 25, 2009 Static Analysis: Data-Flow Analysis II Claus Brabrand IT University of Copenhagen (
Claus Brabrand, UFPE, Brazil Aug 09, 2010DATA-FLOW ANALYSIS Claus Brabrand ((( ))) Associate Professor, Ph.D. ((( Programming, Logic, and.
Ben Livshits Based in part of Stanford class slides from
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Λλ Fernando Magno Quintão Pereira P ROGRAMMING L ANGUAGES L ABORATORY Universidade Federal de Minas Gerais - Department of Computer Science P ROGRAM A.
Constant Propagation. The constant propagation framework is different from all the data-flow problems discussed so far, in that It has an unbounded set.
Abstract Interpretation (Cousot, Cousot 1977) also known as Data-Flow Analysis.
Data Flow Analysis. 2 Source code parsed to produce AST AST transformed to CFG Data flow analysis operates on control flow graph (and other intermediate.
MIT Foundations of Dataflow Analysis Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology.
Solving fixpoint equations
Machine-Independent Optimizations Ⅱ CS308 Compiler Theory1.
Dataflow Analysis Topic today Data flow analysis: Section 3 of Representation and Analysis Paper (Section 3) NOTE we finished through slide 30 on Friday.
Λλ Fernando Magno Quintão Pereira P ROGRAMMING L ANGUAGES L ABORATORY Universidade Federal de Minas Gerais - Department of Computer Science P ROGRAM A.
Compiler Principles Winter Compiler Principles Global Optimizations Mayer Goldberg and Roman Manevich Ben-Gurion University.
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.
CS 614: Theory and Construction of Compilers Lecture 17 Fall 2003 Department of Computer Science University of Alabama Joel Jones.
Formalization of DFA using lattices. Recall worklist algorithm let m: map from edge to computed value at edge let worklist: work list of nodes for each.
Compilation Lecture 8 Abstract Interpretation Noam Rinetzky 1.
Compiler Principles Fall Compiler Principles Lecture 11: Loop Optimizations Roman Manevich Ben-Gurion University.
CS 598 Scripting Languages Design and Implementation 9. Constant propagation and Type Inference.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Chaotic Iterations Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Iterative Dataflow Problems Taken largely from notes of Alex Aiken (UC Berkeley) and Martin Rinard (MIT) Dataflow information used in optimization Several.
Dataflow Analysis CS What I s Dataflow Analysis? Static analysis reasoning about flow of data in program Different kinds of data: constants, variables,
Compiler Principles Fall Compiler Principles Lecture 9: Dataflow & Optimizations 2 Roman Manevich Ben-Gurion University of the Negev.
Lub and glb Given a poset (S, · ), and two elements a 2 S and b 2 S, then the: –least upper bound (lub) is an element c such that a · c, b · c, and 8 d.
DFA foundations Simone Campanoni
Data Flow Analysis Suman Jana
Iterative Dataflow Problems
Simone Campanoni DFA foundations Simone Campanoni
Global optimizations.
University Of Virginia
Flow Analysis Data-flow analysis, Control-flow analysis, Abstract interpretation, AAM.
Fall Compiler Principles Lecture 10: Global Optimizations
Data Flow Analysis Compiler Design
Lecture 20: Dataflow Analysis Frameworks 11 Mar 02
Static Single Assignment
Formalization of DFA using lattices
Formalization of DFA using lattices
Presentation transcript:

Data Flow Analysis II AModel Checking and Abstract Interpretation Feb. 2, 2011

HAPPY GROUNDHOG DAY!

Agenda Recalling last lecture Analysis: Very Busy Expressions {forward,backward}x{may,must} typology Analysis: Live Variables Analysis: Available Expressions Where do we go from here?

Agenda Recalling last lecture Analysis: Very Busy Expressions {forward,backward}x{may,must} typology Analysis: Live Variables Analysis: Available Expressions Where do we go from here?

Recall: Last Lecture Recall: Feynman- 공 Method for data flow analysis Recall: Our programming language Recall: Control Flow Graphs (CFGs) Recall: Reaching Definitions Recall: Reaching Definition Analysis

Recall: Last Lecture Recall: Semilattice, Complete Lattice Recall: Monotone Functions, ACC, and their significance Recall: General Algorithm

Today: Cosmetic Changes Let s be a statement: succ(s) = {immediate successor statements of s} Pred(s) = {immediate predecessor statements of s} In(s) = flow at program point just before executing s Out(s) = flow at program point just after executing s In(s) =  s’ 2 pred(s) Out(s’) (Must) Out(s) = Gen(s) [ (In(s) – Kill(s)) (Forward) Note these are also called transfer functions Gen(s) = set of facts true after s that weren’t true before s Kill(s) = set of facts no longer true after s

Agenda Recalling last lecture Analysis: Very Busy Expressions {forward,backward}x{may,must} typology Analysis: Live Variables Analysis: Available Expressions Where do we go from here?

Very Busy Expressions: Definitions An expression is very busy at the exit from a label if, no matter what path is taken from the label, the expression must always be used before any of the variables occurring in it are redefined. For each program point, which expressions must be very busy at the exit from the point?

Very Busy Expressions: CFG x := b - a 2: a > b 1: y := a - b 3: y := b - a 4: x := a - b 5: true false

Agenda Recalling last lecture Analysis: Very Busy Expressions {forward,backward}x{may,must} typology Analysis: Live Variables Analysis: Available Expressions Where do we go from here?

General Iterative Data Flow Analysis Algorithm (Forward) // Boundary Condition Out[Entry] = V_Entry // Initialization for iterative algorithm For each basic block B Out[B] = Top // iterate while(Changes to any Out[], In[] occur) { For each basic block B { In[B] = meet(Out[p_0],... Out[p_1]) Out[B] = f_B(In[B]) }

Forward Data Flow (General Case) Out(s) = Top for all statements s W := { all statements } (worklist) Repeat Take s from W temp := f s ( ⊓ s ′ ∊ pred(s) Out(s ′ )) (f s monotonic transfer fn) if (temp != Out(s)) { Out(s) := temp W := W [ succ(s) } until W = ∅

Forward Data Flow (General Case) Out(s) = Top for all statements s W := { all statements } (worklist) Repeat Take s from W temp := f s ( ⊓ s ′ ∊ pred(s) Out(s ′ )) (f s monotonic transfer fn) if (temp != Out(s)) { Out(s) := temp W := W [ succ(s) } until W = ∅

Forward vs. Backward Out(s) = Top for all s W := { all statements } repeat Take s from W temp := f s ( ⊓ s′ ∊ pred(s) Out(s′)) if (temp != Out(s)) { Out(s) := temp W := W [ succ(s) } until W = ∅ In(s) = Top for all s W := { all statements } repeat Take s from W temp := f s ( ⊓ s′ ∊ succ(s) In(s′)) if (temp != In(s)) { In(s) := temp W := W [ pred(s) } until W = ∅

Agenda Recalling last lecture Analysis: Very Busy Expressions {forward,backward}x{may,must} typology Analysis: Live Variables Analysis: Available Expressions Where do we go from here?

Live Variables: Definitions A variable is live at the exit from a label if there exists a path from the label to a use of the variable that does not re-define the variable. For each program point, which variables may be live at the exit from the point?

Live Variables: CFG x := 2 1: y := 4 2: x := 1 3: y > x 4: z := y 5: z := y*y 6: x := y 7: true false

Agenda Recalling last lecture Analysis: Very Busy Expressions {forward,backward}x{may,must} typology Analysis: Live Variables Analysis: Available Expressions Where do we go from here?

Available Expressions: Definition For each program point, which expressions must have already been computed, and not later modified, on all paths to the program point.

Available Expressions: CFG x := a + b 1: y := a * b 2: y > a + b 3: a := a + 1 4: z := a + b 5: true false

Agenda Recalling last lecture Analysis: Very Busy Expressions {forward,backward}x{may,must} typology Analysis: Live Variables Analysis: Available Expressions Where do we go from here?

Next? 2.2: Formal correctness proof (Live Variables) Constant Propagation 2.5: Interprocedural Analysis 2.6: Shape Analysis

(Overflow Slides)

Data Flow Facts and lattices Typically, data flow facts form a lattice Example, Available expressions “top” “bottom”

Partial Orders A partial order is a pair (P, · ) such that  · µ P £ P  · is reflexive: x · x  · is anti-symmetric: x · y and y · x implies x = y  · is transitive: x · y and y · z implies x · z

Lattices A partial order is a lattice if u and t are defined so that  u is the meet or greatest lower bound operation  x u y · x and x u y · y  If z · x and z · y then z · x u y  t is the join or least upper bound operation  x · x t y and y · x t y  If x · z and y · z, then x t y · z

Lattices (cont.) A finite partial order is a lattice if meet and join exist for every pair of elements A lattice has unique elements bot and top such that x u ? = ? x t ? =x x u > = x x t > = > In a lattice x · y iff x u y = x x · y iff x t y = y

Useful Lattices (2 S, µ ) forms a lattice for any set S. 2 S is the powerset of S (set of all subsets) If (S, · ) is a lattice, so is (S, ¸ ) i.e., lattices can be flipped The lattice for constant propagation ? > 123 … Note: order on integers is different from order in lattice

Monotonicity A function f on a partial order is monotonic if x · y implies f(x) · f(y) Easy to check that operations to compute In and Out are monotonic In(s) =  s’ 2 pred(s) Out(s’) Temp = Gen(s) [ (In(s) – Kill(s)) Putting the two together Temp = f s (  s’ 2 pred(s) Out(s’))

Termination -- Intuition We know algorithm terminates because The lattice has finite height The operations to compute In and Out are monotonic On every iteration we remove a statement from the worklist and/or move down the lattice.

Lattices (P, ≤ ) Available expressions P = sets of expressions S1 ⊓ S2 = S1 ∩ S2 Top = set of all expressions Reaching Definitions P = set of definitions (assignment statements) S1 ⊓ S2 = S1 [ S2 Top = empty set

Fixpoints -- Intuition We always start with Top Every expression is available, no defns reach this point Most optimistic assumption Strongest possible hypothesis Revise as we encounter contradictions Always move down in the lattice (with meet) Result: A greatest fixpoint

Lattices (P, ≤ ), cont’d Live variables P = sets of variables S1 ⊓ S2 = S1 [ S2 Top = empty set Very busy expressions P = set of expressions S1 ⊓ S2 = S1 ∩ S2 Top = set of all expressions

Least vs. Greatest Fixpoints Dataflow tradition: Start with Top, use meet To do this, we need a meet semilattice with top meet semilattice = meets defined for any set Computes greatest fixpoint Denotational semantics tradition: Start with Bottom, use join Computes least fixpoint

Must vs. May (Not always followed in literature) Forwards vs. Backwards Flow-sensitive vs. Flow-insensitive Distributive vs. Non-distributive Terminology Review