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.

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

Tutorial on Widening (and Narrowing) Hongseok Yang Seoul National University.
1 CS 201 Compiler Construction Data Flow Framework.
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.
CSE 231 : Advanced Compilers Building Program Analyzers.
CSE 231 : Advanced Compilers Building Program Analyzers.
Common Sub-expression Elim Want to compute when an expression is available in a var Domain:
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.
Recap from last time We were trying to do Common Subexpression Elimination Compute expressions that are available at each program point.
Another example: constant prop Set D = 2 { x ! N | x ∊ Vars Æ N ∊ Z } x := N in out F x := N (in) = in – { x ! * } [ { x ! N } x := y op z in out F x :=
Correctness. Until now We’ve seen how to define dataflow analyses How do we know our analyses are correct? We could reason about each individual analysis.
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 –
1 Iterative Program Analysis Part I Mooly Sagiv Tel Aviv University Textbook: Principles of Program.
Another example: constant prop Set D = 2 { x ! N | x 2 Vars Æ N 2 Z } x := N in out F x := N (in) = in – { x ! * } [ { x ! N } x := y op z in out F x :=
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.
Constraints for reaching definitions Using may-point-to information: out = in [ { x ! s | x 2 may-point-to(p) } Using must-point-to aswell: out = in –
1 Iterative Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Back to lattice (D, v, ?, >, t, u ) = (2 A, ¶, A, ;, Å, [ ) where A = { x ! N | x 2 Vars Æ N 2 Z } What’s the problem with this lattice? Lattice is infinitely.
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.
Administrative stuff Office hours: After class on Tuesday.
Recap Let’s do a recap of what we’ve seen so far Started with worklist algorithm for reaching definitions.
Constraints for reaching definitions Using may-point-to information: out = in [ { x ! s | x 2 may-point-to(p) } Using must-point-to aswell: out = in –
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.
Project Project proposal due today (lots of projects have already sent theirs in!) I want some concrete results in 3 weeks! –for implementation projects,
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.
From last lecture x := y op z in out F x := y op z (in) = in [ x ! in(y) op in(z) ] where a op b =
Direction of analysis Although constraints are not directional, flow functions are All flow functions we have seen so far are in the forward direction.
Projects. Dataflow analysis Dataflow analysis: what is it? A common framework for expressing algorithms that compute information about a program Why.
Project web page
1 CS 201 Compiler Construction Lecture 4 Data Flow Framework.
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.
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.
Even more formal To reason more formally about termination and precision, we re-express our worklist algorithm mathematically We will use fixed points.
Termination Still, it’s annoying to have to perform a join in the worklist algorithm It would be nice to get rid of it, if there is a property of the flow.
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Sets, POSets, and Lattice © Marcelo d’Amorim 2010.
Precision Going back to constant prop, in what cases would we lose precision?
Abstract Interpretation (Cousot, Cousot 1977) also known as Data-Flow Analysis.
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.
Solving fixpoint equations
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.
Compiler Principles Fall Compiler Principles Lecture 11: Loop Optimizations Roman Manevich Ben-Gurion University.
Data Flow Analysis II AModel Checking and Abstract Interpretation Feb. 2, 2011.
Semilattices presented by Niko Simonson, CSS 548, Autumn 2012 Semilattice City, © 2009 Nora Shader.
1 Iterative Program Analysis Part II Mathematical Background Mooly Sagiv Tel Aviv University
Chaotic Iterations Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Chaotic Iterations Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
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
Dataflow analysis.
Simone Campanoni DFA foundations Simone Campanoni
Another example: constant prop
Dataflow analysis.
Data Flow Analysis Compiler Design
Background material.
Formalization of DFA using lattices
Background material.
Formalization of DFA using lattices
Formalization of DFA using lattices
Formalization of DFA using lattices
Presentation transcript:

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 from S have a lub and a glb – t is the least upper bound operator, called a join – u is the greatest lower bound operator, called a meet

Examples of lattices Powerset lattice

Examples of lattices Powerset lattice

Examples of lattices Booleans expressions

Examples of lattices Booleans expressions

Examples of lattices Booleans expressions

Examples of lattices Booleans expressions

End of background material

Back to our example let m: map from edge to computed value at edge let worklist: work list of nodes for each edge e in CFG do m(e) := ; for each node n do worklist.add(n) while (worklist.empty.not) do let n := worklist.remove_any; let info_in := m(n.incoming_edges); let info_out := F(n, info_in); for i := 0.. info_out.length do let new_info := m(n.outgoing_edges[i]) [ info_out[i]; if (m(n.outgoing_edges[i])  new_info]) m(n.outgoing_edges[i]) := new_info; worklist.add(n.outgoing_edges[i].dst);

Back to our example We formalize our domain with a powerset lattice What should be top and what should be bottom?

Back to our example We formalize our domain with a powerset lattice What should be top and what should be bottom? Does it matter? –It matters because, as we’ve seen, there is a notion of approximation, and this notion shows up in the lattice

Direction of lattice Unfortunately: –dataflow analysis community has picked one direction –abstract interpretation community has picked the other We will work with the abstract interpretation direction Bottom is the most precise (optimistic) answer, Top the most imprecise (conservative)

Direction of lattice Always safe to go up in the lattice Can always set the result to > Hard to go down in the lattice So... Bottom will be the empty set in reaching defs

Worklist algorithm using lattices let m: map from edge to computed value at edge let worklist: work list of nodes for each edge e in CFG do m(e) := ? for each node n do worklist.add(n) while (worklist.empty.not) do let n := worklist.remove_any; let info_in := m(n.incoming_edges); let info_out := F(n, info_in); for i := 0.. info_out.length do let new_info := m(n.outgoing_edges[i]) t info_out[i]; if (m(n.outgoing_edges[i])  new_info]) m(n.outgoing_edges[i]) := new_info; worklist.add(n.outgoing_edges[i].dst);

Termination of this algorithm? For reaching definitions, it terminates... Why? –lattice is finite Can we loosen this requirement? –Yes, we only require the lattice to have a finite height Height of a lattice: length of the longest ascending or descending chain Height of lattice (2 S, µ ) =

Termination of this algorithm? For reaching definitions, it terminates... Why? –lattice is finite Can we loosen this requirement? –Yes, we only require the lattice to have a finite height Height of a lattice: length of the longest ascending or descending chain Height of lattice (2 S, µ ) = | S |

Termination Still, it’s annoying to have to perform a join in the worklist algorithm It would be nice to get rid of it, if there is a property of the flow functions that would allow us to do so while (worklist.empty.not) do let n := worklist.remove_any; let info_in := m(n.incoming_edges); let info_out := F(n, info_in); for i := 0.. info_out.length do let new_info := m(n.outgoing_edges[i]) t info_out[i]; if (m(n.outgoing_edges[i])  new_info]) m(n.outgoing_edges[i]) := new_info; worklist.add(n.outgoing_edges[i].dst);

Even more formal To reason more formally about termination and precision, we re-express our worklist algorithm mathematically We will use fixed points to formalize our algorithm

Fixed points Recall, we are computing m, a map from edges to dataflow information Define a global flow function F as follows: F takes a map m as a parameter and returns a new map m’, in which individual local flow functions have been applied

Fixed points We want to find a fixed point of F, that is to say a map m such that m = F(m) Approach to doing this? Define ?, which is ? lifted to be a map: ? = e. ? Compute F( ? ), then F(F( ? )), then F(F(F( ? ))),... until the result doesn’t change anymore

Fixed points Formally: We would like the sequence F i ( ? ) for i = 0, 1, 2... to be increasing, so we can get rid of the outer join Require that F be monotonic: – 8 a, b. a v b ) F(a) v F(b)

Fixed points

Back to termination So if F is monotonic, we have what we want: finite height ) termination, without the outer join Also, if the local flow functions are monotonic, then global flow function F is monotonic

Another benefit of monotonicity Suppose Marsians came to earth, and miraculously give you a fixed point of F, call it fp. Then:

Another benefit of monotonicity Suppose Marsians came to earth, and miraculously give you a fixed point of F, call it fp. Then:

Another benefit of monotonicity We are computing the least fixed point...

Recap Let’s do a recap of what we’ve seen so far Started with worklist algorithm for reaching definitions

Worklist algorithm for reaching defns let m: map from edge to computed value at edge let worklist: work list of nodes for each edge e in CFG do m(e) := ; for each node n do worklist.add(n) while (worklist.empty.not) do let n := worklist.remove_any; let info_in := m(n.incoming_edges); let info_out := F(n, info_in); for i := 0.. info_out.length do let new_info := m(n.outgoing_edges[i]) [ info_out[i]; if (m(n.outgoing_edges[i])  new_info]) m(n.outgoing_edges[i]) := new_info; worklist.add(n.outgoing_edges[i].dst);

Generalized algorithm using lattices let m: map from edge to computed value at edge let worklist: work list of nodes for each edge e in CFG do m(e) := ? for each node n do worklist.add(n) while (worklist.empty.not) do let n := worklist.remove_any; let info_in := m(n.incoming_edges); let info_out := F(n, info_in); for i := 0.. info_out.length do let new_info := m(n.outgoing_edges[i]) t info_out[i]; if (m(n.outgoing_edges[i])  new_info]) m(n.outgoing_edges[i]) := new_info; worklist.add(n.outgoing_edges[i].dst);

Next step: removed outer join Wanted to remove the outer join, while still providing termination guarantee To do this, we re-expressed our algorithm more formally We first defined a “global” flow function F, and then expressed our algorithm as a fixed point computation

Guarantees If F is monotonic, don’t need outer join If F is monotonic and height of lattice is finite: iterative algorithm terminates If F is monotonic, the fixed point we find is the least fixed point. Any questions so far?

What about if we start at top? What if we start with > : F( > ), F(F( > )), F(F(F( > )))

What about if we start at top? What if we start with > : F( > ), F(F( > )), F(F(F( > ))) We get the greatest fixed point Why do we prefer the least fixed point? –More precise

Graphically x y 10

Graphically x y 10

Graphically x y 10

Graphically, another way

Another example: constant prop Set D = x := N in out F x := n (in) = x := y op z in out F x := y op z (in) =

Another example: constant prop Set D = 2 { x ! N | x 2 Vars Æ N 2 Z } x := N in out F x := n (in) = in – { x ! * } [ { x ! N } x := y op z in out F x := y op z (in) = in – { x ! * } [ { x ! N | ( y ! N 1 ) 2 in Æ ( z ! N 2 ) 2 in Æ N = N 1 op N 2 }

Another example: constant prop *x := y in out F *x := y (in) = x := *y in out F x := *y (in) =

Another example: constant prop *x := y in out F *x := y (in) = in – { z ! * | z 2 may-point(x) } [ { z ! N | z 2 must-point-to(x) Æ y ! N 2 in } [ { z ! N | (y ! N) 2 in Æ (z ! N) 2 in } x := *y in out F x := *y (in) = in – { x ! * } [ { x ! N | 8 z 2 may-point-to(x). (z ! N) 2 in }