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 –

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.
Control-Flow Graphs & Dataflow Analysis CS153: Compilers Greg Morrisett.
Intermediate Representations Saumya Debray Dept. of Computer Science The University of Arizona Tucson, AZ
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
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.
Intermediate Representation I High-Level to Low-Level IR Translation EECS 483 – Lecture 17 University of Michigan Monday, November 6, 2006.
CS412/413 Introduction to Compilers Radu Rugina Lecture 16: Efficient Translation to Low IR 25 Feb 02.
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.
Representing programs Goals. Representing programs Primary goals –analysis is easy and effective just a few cases to handle directly link related things.
Recap from last time Saw several examples of optimizations –Constant folding –Constant Prop –Copy Prop –Common Sub-expression Elim –Partial Redundancy.
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.
1 Intermediate representation Goals: –encode knowledge about the program –facilitate analysis –facilitate retargeting –facilitate optimization scanning.
Administrative info Subscribe to the class mailing list –instructions are on the class web page, which is accessible from my home page, which is accessible.
Chair of Software Engineering Fundamentals of Program Analysis Dr. Manuel Oriol.
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.
Another example p := &x; *p := 5 y := x + 1;. Another example p := &x; *p := 5 y := x + 1; x := 5; *p := 3 y := x + 1; ???
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.
CS 412/413 Spring 2007Introduction to Compilers1 Lecture 29: Control Flow Analysis 9 Apr 07 CS412/413 Introduction to Compilers Tim Teitelbaum.
Class canceled next Tuesday. Recap: Components of IR Control dependencies: sequencing of operations –evaluation of if & then –side-effects of statements.
Recap Let’s do a recap of what we’ve seen so far Started with worklist algorithm for reaching definitions.
Data Flow Analysis Compiler Design Nov. 8, 2005.
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.
ESP [Das et al PLDI 2002] Interface usage rules in documentation –Order of operations, data access –Resource management –Incomplete, wordy, not checked.
Topic 6 -Code Generation Dr. William A. Maniatty Assistant Prof. Dept. of Computer Science University At Albany CSI 511 Programming Languages and Systems.
Projects. Dataflow analysis Dataflow analysis: what is it? A common framework for expressing algorithms that compute information about a program Why.
Recap from last time: live variables x := 5 y := x + 2 x := x + 1 y := x y...
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 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.
Composing Dataflow Analyses and Transformations Sorin Lerner (University of Washington) David Grove (IBM T.J. Watson) Craig Chambers (University of Washington)
Even more formal To reason more formally about termination and precision, we re-express our worklist algorithm mathematically We will use fixed points.
Recap from last time We saw various different issues related to program analysis and program transformations You were not expected to know all of these.
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.
Pointer analysis. Pointer Analysis Outline: –What is pointer analysis –Intraprocedural pointer analysis –Interprocedural pointer analysis Andersen and.
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Precision Going back to constant prop, in what cases would we lose precision?
High level & Low level language High level programming languages are more structured, are closer to spoken language and are more intuitive than low level.
Example x := read() v := a + b x := x + 1 w := x + 1 a := w v := a + b z := x + 1 t := a + b.
10/1/2015© Hal Perkins & UW CSEG-1 CSE P 501 – Compilers Intermediate Representations Hal Perkins Autumn 2009.
Compiler Principles Fall Compiler Principles Lecture 0: Local Optimizations Roman Manevich Ben-Gurion University.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
1 Control Flow Analysis Topic today Representation and Analysis Paper (Sections 1, 2) For next class: Read Representation and Analysis Paper (Section 3)
Program Representations. Representing programs Goals.
CS412/413 Introduction to Compilers Radu Rugina Lecture 18: Control Flow Graphs 29 Feb 02.
1 Control Flow Graphs. 2 Optimizations Code transformations to improve program –Mainly: improve execution time –Also: reduce program size Can be done.
1 Iterative Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program.
Data Flow Analysis II AModel Checking and Abstract Interpretation Feb. 2, 2011.
DFA foundations Simone Campanoni
Data Flow Analysis Suman Jana
Dataflow analysis.
Program Representations
G. Ramalingam Microsoft Research, India & K. V. Raghavan
Topic 10: Dataflow Analysis
University Of Virginia
Another example: constant prop
Dataflow analysis.
Optimizations using SSA
Data Flow Analysis Compiler Design
Pointer analysis.
Presentation transcript:

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 – { x } [ { y, z}

Example: live variables x := 5 y := x + 2 x := x + 1 y := x y...

Revisiting assignment x := y op z in out F x := y op z (out) = out – { x } [ { y, z}

Revisiting assignment x := y op z in out F x := y op z (out) = out – { x } [ { y, z}

Theory of backward analyses Can formalize backward analyses in two ways Option 1: reverse flow graph, and then run forward problem Option 2: re-develop the theory, but in the backward direction

Precision Going back to constant prop, in what cases would we lose precision?

Precision Going back to constant prop, in what cases would we lose precision? if (p) { x := 5; } else x := 4; }... if (p) { y := x + 1 } else { y := x + 2 }... y... if (...) { x := -1; } else x := 1; } y := x * x;... y... x := 5 if ( ) { x := 6 }... x... where is equiv to false

Precision The first problem: Unreachable code –solution: run unreachable code removal before –the unreachable code removal analysis will do its best, but may not remove all unreachable code The other two problems are path-sensitivity issues –Branch correlations: some paths are infeasible –Path merging: can lead to loss of precision

MOP: meet over all paths Information computed at a given point is the meet of the information computed by each path to the program point if (...) { x := -1; } else x := 1; } y := x * x;... y...

MOP For a path p, which is a sequence of statements [s 1,..., s n ], define: F p (in) = F s n (...F s 1 (in)... ) In other words: F p = Given an edge e, let paths-to(e) be the (possibly infinite) set of paths that lead to e Given an edge e, MOP(e) = For us, should be called JOP (ie: join, not meet)

MOP vs. dataflow MOP is the “best” possible answer, given a fixed set of flow functions –This means that MOP v dataflow at edge in the CFG In general, MOP is not computable (because there can be infinitely many paths) –vs dataflow which is generally computable (if flow fns are monotonic and height of lattice is finite) And we saw in our example, in general, MOP  dataflow

MOP vs. dataflow However, it would be great if by imposing some restrictions on the flow functions, we could guarantee that dataflow is the same as MOP. What would this restriction be? x := -1; y := x * x;... y... x := 1; y := x * x;... y... Merge x := -1;x := 1; Merge y := x * x;... y... DataflowMOP

MOP vs. dataflow However, it would be great if by imposing some restrictions on the flow functions, we could guarantee that dataflow is the same as MOP. What would this restriction be? Distributive problems. A problem is distributive if: 8 a, b. F(a t b) = F(a) t F(b) If flow function is distributive, then MOP = dataflow

Summary of precision Dataflow is the basic algorithm To basic dataflow, we can add path-separation –Get MOP, which is same as dataflow for distributive problems –Variety of research efforts to get closer to MOP for non-distributive problems To basic dataflow, we can add path-pruning –Get branch correlation To basic dataflow, can add both: –meet over all feasible paths

Program Representations

Representing programs Goals

Representing programs Primary goals –analysis is easy and effective just a few cases to handle directly link related things –transformations are easy to perform –general, across input languages and target machines Additional goals –compact in memory –easy to translate to and from –tracks info from source through to binary, for source-level debugging, profilling, typed binaries –extensible (new opts, targets, language features) –displayable

Option 1: high-level syntax based IR Represent source-level structures and expressions directly Example: Abstract Syntax Tree

Option 2: low-level IR Translate input programs into low-level primitive chunks, often close to the target machine Examples: assembly code, virtual machine code (e.g. stack machines), three-address code, register-transfer language (RTL) Standard RTL instrs:

Option 2: low-level IR