1 Program Analysis Mooly Sagiv Tel Aviv University 640-6706 Textbook: Principles of Program Analysis.

Slides:



Advertisements
Similar presentations
Semantics Static semantics Dynamic semantics attribute grammars
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.
Interprocedural Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday
Compilation 2011 Static Analysis Johnni Winther Michael I. Schwartzbach Aarhus University.
Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis – today’s class –Classic analyses.
3-Valued Logic Analyzer (TVP) Tal Lev-Ami and Mooly Sagiv.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Chair of Software Engineering From Program slicing to Abstract Interpretation Dr. Manuel Oriol.
INF 212 ANALYSIS OF PROG. LANGS Type Systems Instructors: Crista Lopes Copyright © Instructors.
Compiling Object Oriented Programs Mooly Sagiv Chapter
Lecture 15 – Dataflow Analysis Eran Yahav 1
Lecture 02 – Structural Operational Semantics (SOS) Eran Yahav 1.
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.
Program analysis Mooly Sagiv html://
CS 536 Spring Global Optimizations Lecture 23.
Control Flow Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Global optimization. Data flow analysis To generate better code, need to examine definitions and uses of variables beyond basic blocks. With use- definition.
1 Iterative Program Analysis Part I Mooly Sagiv Tel Aviv University Textbook: Principles of Program.
Liveness Analysis Mooly Sagiv Schrierber Wed 10:00-12:00 html://
Program analysis Mooly Sagiv html://
1 Control Flow Analysis Mooly Sagiv Tel Aviv University Textbook Chapter 3
1 Iterative Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Programming Language Semantics Mooly SagivEran Yahav Schrirber 317Open space html://
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.
Interprocedural Analysis Noam Rinetzky Mooly Sagiv Tel Aviv University Textbook Chapter 2.5.
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Overview of program analysis Mooly Sagiv html://
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
1 Program Analysis Systematic Domain Design Mooly Sagiv Tel Aviv University Textbook: Principles.
Machine-Independent Optimizations Ⅰ CS308 Compiler Theory1.
Data Flow Analysis Compiler Design Nov. 8, 2005.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Overview of program analysis Mooly Sagiv html://
CHAPTER 10 Recursion. 2 Recursive Thinking Recursion is a programming technique in which a method can call itself to solve a problem A recursive definition.
Ben Livshits Based in part of Stanford class slides from
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Compiling Object Oriented Programs Mooly Sagiv Chapter 6.2.9, 6.5.
1 Tentative Schedule u Today: Theory of abstract interpretation u May 5 Procedures u May 15, Orna Grumberg u May 12 Yom Hatzamaut u May.
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 5 Data Flow Testing
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
1 Iterative Program Analysis Abstract Interpretation Mooly Sagiv Tel Aviv University Textbook:
Type Systems CS Definitions Program analysis Discovering facts about programs. Dynamic analysis Program analysis by using program executions.
CSE 501N Fall ‘09 12: Recursion and Recursive Algorithms 8 October 2009 Nick Leidenfrost.
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.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
© 2011 Pearson Education, publishing as Addison-Wesley Chapter 8: Recursion Presentation slides for Java Software Solutions for AP* Computer Science 3rd.
Principle of Programming Lanugages 3: Compilation of statements Statements in C Assertion Hoare logic Department of Information Science and Engineering.
Recursion A recursive definition is one which uses the word or concept being defined in the definition itself Example: “A computer is a machine.
Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications Chapter.
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.
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Chaotic Iterations Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Chaotic Iterations Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
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.
Program Analysis Last Lesson Mooly Sagiv. Goals u Show the significance of set constraints for CFA of Object Oriented Programs u Sketch advanced techniques.
Textbook: Principles of Program Analysis
Compiler Design 18. Object Oriented Semantic Analysis (Symbol Tables, Type Checking) Kanat Bolazar March 30, 2010.
Iterative Program Analysis Abstract Interpretation
Unit 3 Test: Friday.
Data Flow Analysis Compiler Design
Software Testing and QA Theory and Practice (Chapter 5: Data Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Presentation transcript:

1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis Chapter 1.1-4

Goals u Sketch existing program analysis techniques u Fixed point theory in the nutshell u Relationship between program analysis and operational semantics

Outline u The Nature of Program Analysis u Setting the Scene –The While language –Reaching Definitions u Program Analysis Techniques –Data Flow Analysis - the equational approach –The Constraint Based Approach –Mathematical background –Abstract Interpretation –Type and Effect Systems –Algorithms –Transformations Next week

The Nature of Program Analysis u Compile-time techniques for predicating safe and computable approximations to the behaviors arising at runtime when executing a program u Differences with operational semantics –The input state is not usually known at compile-time –The compiler must always terminate (fast) –The compiler can generate suboptimal code

The Nature of Program Analysis Erring on the Safe Side {d 1, d 2, …, d N } {d 1, d 2, …, d n d N } true-answer {d 1, d 2, …, d n, d n+1, … d n+m, d N } safe-answer

Example void main() {int y, z; read(x); if (x>0) then y = 1; else { y = 2; f() ; /* f does not change y */ } z = y; } /* y  {1, 2} */

Example void main() {int y, z; read(x); if (x>0) then y = 1; else { y = 2; f() ; /* f does not change y */ } z = y; } /* y  {1} */

Example void main() {int y, z; read(x); if (x>0) then y = 1; else { y = 2; f() ; /* f does not change y */ } z = y; } /* y  {1, 2, 27} */

Semantics Based Program Analysis u Information obtained can be proved safe (or correct) w.r.t. operational semantics u Earlier detection of conceptual compiler bugs u But not committing to semantics directed program analysis –The structure of the program analysis algorithm need reflect the structure of the semantics

The While Programming Language Revisited Syntactical Categories u x, y  Var program variables u n  Num program numerals u a  Aexp arithmetic expressions u b  Bexp Boolean expressions u s  Stm set of program statements u l  Lab set of program labels u op a  Op a arithmetic operators u op b  Op b Boolean operators u op r  Op b relational operators

The While Programming Language Revisited Abstract Syntax a := x | n | a 1 op a a 2 b := true | false | not b | b 1 op b b 2 | a 1 op r a 2 S := [x := a] l | [skip] l | S 1 ; S 2 | if [b] l then S 1 else S 2 | while [b] l do S

The Factorial Program [y := x] 1 ; [z := 1] 2 ; while [y>1] 3 do ( [z:= z * y] 4 ; [y := y - 1] 5 ; ) [y := 0] 6 ;

Example Program Analysis Problem Reaching Definitions u An assignment (definition) of the form [x := a] l may reach an elementary block l’ if – there is execution of the program that leads to l' where x was last assigned at l

Reaching Definitions in Factorial [y := x] 1 ; [z := 1] 2 ; while [y>1] 3 do ( [z:= z * y] 4 ; [y := y - 1] 5 ; ) [y := 0] 6 ; {(x, ?), (y, ?), (z, ?)} {(x, ?), (y, 1), (z, ?)} {(x, ?), (y, 1), (z, 2)} {(x, ?), (y, 1), (y, 5), (z, 2), (z, 4)} {(x, ?), (y, 1), (y, 5), (z, 4)} {(x, ?), (y, 5), (z, 4)} {(x, ?), (y, 6), (z, 2), (z, 4)} {(x, ?), (y, 1), (y, 5), (z, 2), (z, 4)}

Reaching Definitions in Factorial

Usage of Reaching Definitions u Compiler optimizations –An occurrence of a variable x in in an elementary block l is constant n if all in the reaching definitions (x, l'), l' assigns n to x –Loop invariant code motion –Program dependence graphs u Software quality tools –A usage of a variable x in an elementary block may be uninitialized if... –Program slicing

Soundness in Reaching Definitions u Every reachable definition is detected u May include more definitions –Less constants may be identified –Not all the loop invariant code will be identified –May warn against uninitailzed variables that are in fact in initialized u But never miss a reaching definition –All constants are indeed such –Never move a non invariant code –Never miss an error

Reaching Definitions in Factorial [y := x] 1 ; [z := 1] 2 ; while [y>1] 3 do ( [z:= z * y] 4 ; [y := y - 1] 5 ; ) [y := 0] 6 ; {(x, ?), (y, ?), (z, ?)} {(x, ?), (y, 1), (z, ?)} {(x, ?), (y, 1), (z, 2)} {(x, ?), (y, 1), (y, 5), (z, 2), (z, 4)} {(x, ?), (y, 1), (y, 5), (z, 4)} {(x, ?), (y, 5), (z, 4)} {(x, ?), (y, 6), (z, 2), (z, 4)} {(x, ?), (y, 1), (y, 5), (z, 2), (z, 4)}

Unsound Reaching Definitions 1 [y := x] 1 ; [z := 1] 2 ; while [y>1] 3 do ( [z:= z * y] 4 ; [y := y - 1] 5 ; ) [y := 0] 6 ; {(x, ?), (y, ?), (z, ?)} {(x, ?), (y, 1), (z, ?)} {(x, ?), (y, 1), (z, 2)} {(x, ?), (y, 1), (y, 5), (z, 2), (z, 4)} {(x, ?), (y, 1), (z, 2)} {(x, ?), (y, 1), (z, 4)} {(x, ?), (y, 5), (z, 4)} {(x, ?), (y, 6), (z, 2), (z, 4)} {(x, ?), (y, 1), (z, 2)}

Unsound Reaching Definitions 2 [y := x] 1 ; [z := 1] 2 ; while [y>1] 3 do ( [z:= z * y] 4 ; [y := y - 1] 5 ; ) [y := 0] 6 ; {(x, ?), (y, ?), (z, ?)} {(x, ?), (y, 1), (z, ?)} {(x, ?), (y, 1), (z, 2)} {(x, ?), (y, 5), (z, 4)} {(x, ?), (y, 1), (y, 5), (z, 2), (z, 4)} {(x, ?), (y, 1), (y, 5), (z, 4)} {(x, ?), (y, 5), (z, 4)} {(x, ?), (y, 6), (z, 4)} {(x, ?), (y, 1), (y, 5), (z, 2), (z, 4)}

Suboptimal Reaching Definitions [y := x] 1 ; [z := 1] 2 ; while [y>1] 3 do ( [z:= z * y] 4 ; [y := y - 1] 5 ; ) [y := 0] 6 ; {(x, ?), (y, ?), (z, ?)} {(x, ?), (y, 1), (z, ?)} {(x, ?), (y, 1), (z, 2)} {(x, ?), (y, 1), (y, 5), (y, 6), (z, 2), (z, 4)} {(x, ?), (y, 1), (y, 6), (y, 5), (z, 4)} {(x, ?), (y, 1), (y, 5), (y, 6), (z, 4)} {(x, ?), (y, 5), (z, 4)} {(x, ?), (y, 6), (z, 2), (z, 4)} {(x, ?), (y, 1), (y, 5), (y, 6), (z, 2), (z, 4)}

Program Analysis Techniques u Find sound solutions u Data Flow Analysis - the equational approach u Abstract Interpretation u The Constraint Based Approach u Type and Effect Systems

The Dataflow Analysis Approach u Generate a system of equations u Find the least solution in one of the following ways –Start with the minimum element and iterate until no more changes occur –Eliminate equations until every value is expressed in terms of the initial dataflow value when the program begins (not studied in this course)

Equations Generated for Reaching Definitions u Equations for elementary statements –[skip] l RD exit (1) = RD entry (l) –[b] l RD exit (1) = RD entry (l) –[x := a] l RD exit (1) = (RD entry (l) - {(x, l’) | l’  Lab })  {(x, l)} u Equations for control flow constructs RD entry (l) =  RD exit (l’) l’ immediately precedes l in the control flow graph u An equation for the entry RD entry (1) = {(x, ?) | x is a variable in the program}

RDentry(1)={(x, ?), (y, ?), (z, ?)} RDexit(1)= RDentry(1)-{(y, l’) | l’  Lab })  {(y, 1)} RDentry(2) = RDexit(1) RDexit(2)= RDentry(2)-{(z, l’) | l’  Lab })  {(z, 2)} RDentry(3) = RDexit(2)  RDexit(5) RDexit(3) = RDentry(3) RDentry(4) = RDexit(3) RDexit(4)= RDentry(4)-{(z, l’) | l’  Lab })  {(z, 4)} RDentry(5) = RDexit(4) RDexit(5)= RDentry(5)-{(y, l’) | l’  Lab })  {(y, 5)} RDentry(6) = RDexit(6) RDexit(6)= RDentry(6)-{(y, l’) | l’  Lab })  {(y, 6)} [y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ;

The Least Solution u 12 equations over sets RD entry (1), …, RD exit (6) u Can be written in vectorial form u Find the minimum solution u Every component is minimal u Since F is monotonic such a solution always exists u Since the number of definitions is finite it is possible to compute the minimum solution iteratively

Chaotic Computation of the Least Solution Initialize RD entry (1):={(x, ?), (y, ?), (z, ?)}; RDexit (1):=  RD entry (2):=  ; RDexit (2):=  RD entry (3):=  ; RDexit (3):=  RD entry (4):=  ; RDexit(4) :=  RD entry (5):=  ; RDexit(5):=  RD entry (6):=  ; RDexit(6):=  WL = {1, 2, 3, 4, 5, 6} while WL !=  do select and remove an l from WL new := FRD exit (l)(…) if (new != RD exit (l)) then RD exit (l) := new for all l’ such that RD exit (l) is used in FRD entry (l’)(…) do RD entry (l’) := RD entry (l’)  new WL := WL  {l’}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:4)} {(x, ?), (y:1), (z:2)}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:4)} {(x:?), (y: 5), (z: 4)}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} 3 {(x: ?), (y:1), (z:2), (y: 5), (z: 4)} {6, 4} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:4)} {(x:?), (y: 5), (z: 4)}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} 3 {(x: ?), (y:1), (z:2), (y: 5), (z: 4)} {6, 4} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x, ?), (y:1), (z:4)} {(x:?), (y: 5), (z: 4)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x:?), (y:5), (z:4)}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} 3 {(x: ?), (y:1), (z:2), (y: 5), (z: 4)} {6, 4} 4 {(x:?), (y:1), (y:5), (z:4)} {6, 5} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x, ?), (y:1), (z:4)} {(x:?), (y: 5), (z: 4)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x:?), (y:5), (z:4)}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} 3 {(x: ?), (y:1), (z:2), (y: 5), (z: 4)} {6, 4} 4 {(x:?), (y:1), (y:5), (z:4)} {6, 5} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x, ?), (y:1), (z:4), (y:5)} {(x, ?), (y:1), (z:4), (y: 5)} {(x:?), (y: 5), (z: 4)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x:?), (y:5), (z:4)}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} 3 {(x: ?), (y:1), (z:2), (y: 5), (z: 4)} {6, 4} 4 {(x:?), (y:1), (y:5), (z:4)} {6, 5} 5 {(x:?), (y: 5), (y:5)}{6} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x, ?), (y:1), (z:4), (y:5)} {(x:?), (y: 5), (z: 4)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x:?), (y:5), (z:4)}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} 3 {(x: ?), (y:1), (z:2), (y: 5), (z: 4)} {6, 4} 4 {(x:?), (y:1), (y:5), (z:4)} {6, 5} 5 {(x:?), (y: 5), (y:5)}{6} 6 {(x:?), (y: 6), (z: 2), (z:4)} {} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x, ?), (y:1), (z:4), (y:5)} {(x:?), (y: 5), (z: 4)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x:?), (y:5), (z:4)}

[y := x] 1 ; [z := 1] 2 ; [y>1] 3 [z:= z * y] 4 [y := y - 1] 5 ; [y := 0] 6 ; lRDexit(l)WL {1, 2, 3, 4, 5, 6} 1 {(x, ?), (y:1), (z:?)}{2, 3, 4, 5, 6} 2 {(x, ?), (y:1), (z:2)}{3, 4, 5, 6} 3 {(x, ?), (y:1), (z:2)}{4, 5, 6} 4 {(x, ?), (y:1), (z:4)}{5, 6} 5 {(x:?), (y: 5), (z: 4)}{6, 3} 3 {(x: ?), (y:1), (z:2), (y: 5), (z: 4)} {6, 4} 4 {(x:?), (y:1), (y:5), (z:4)} {6, 5} 5 {(x:?), (y: 5), (y:5)}{6} 6 {(x:?), (y: 6), (z: 2), (z:4)} {} (x, ?), (y, ?), (z, ?)}{(x, ?), (y:1), (z:?)} {(x, ?), (y:1), (z:2)} {(x, ?), (y:1), (z:2), (y: 5), (z:4)} {(x, ?), (y:1), (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:5), (z:4)}

The Constraint Based Approach u Generate a system of set inclusions X  Y u Fits very well with functional and object oriented programming languages in which the control flow graph is not immediately derived from the syntax u Find the least solution

Constraints Generated for Reaching Definitions u Constrains for elementary statements –[skip] l RD exit (1)  RD entry (l) –[b] l RD exit (1)  RD entry (l) –[x := a] l RD exit (1)  (RD entry (l) - {(x, l) | l  Lab }) RD exit (1)  {(x, l)} u Equations for control flow constructs RDentry(l)  RD exit (l’) – l’ immediately precedes l in the control flow graph u An equation for the entry RD entry (1)  {(x, ?) | x is a variable in the program}

Constraint vs. Equations Reaching Definitions u Every solution to the system of equations is a solution to the set of constraints RD exit (1)  (RD entry (l) - {(x, l) | l  Lab }) RD exit (1)  {(x, l)} RD exit (1)  (RD entry (l) - {(x, l) | l  Lab })  {(x, l)} u But some solutions to the set of constraints are not solutions to the system of equations u The least solution is the same u The connection between constraints and equations is not always obvious

The Control Flow Analysis Problem u Given a program in a functional programming language with higher order functions (functions can serve as parameters and return values) u Find out for each function invocation which functions may be applied u Obvious in C without function pointers u Difficult in C++, Java and ML

An ML Example let f = fn x => x 1 ; g = fn y => y + 2 ; h = fn z => z + 3; in (f g) + (f h)

An ML Example let f = fn x => /* {g, h} */ x 1 ; g = fn y => y + 2 ; h = fn z => z + 3; in (f g) + (f h)

Control Flow Analysis (pure)ML u Find out for every formal argument x the set of expressions that may be bound to x in some execution u Analyze all function invocations u Generate a set of constraints –Label every program sub-expression –The Control Flow Analysis Algorithm needs to find a pair (C, p) where »C(l) is a superset of the potential sub-expressions that can occur at l »p(x) is a superset of the potential sub-expressions that x can be bound to u Generate constraints for (C, p)

Simplified Example let f = [ fn x => [[x] 1 1] 2 ] 3 ; g = [ fn y =>[[y] 4 + 2] 5 ] 6 ; h = [ fn z =>[[z] 7 + 3] 8 ] 9 ; in [f h] 10

Simplified Constraints let f = [ fn x => [[x] 1 1] 2 ] 3 ; g = [ fn y =>[[y] 4 + 2] 5 ] 6 ; h = [ fn z =>[[z] 7 + 3] 8 ] 9 ; in [f h] 10 C(1)  { [x] 1 } C(2)  { [[x] 1 1] 2 … C(10)  {[f h] 10 } C(1)  p(x) C(4)  p(y) C(7)  p(z) p(x)  C(9) C(10)  C(3)

OO Example Class Vehicle extends object { int position; public Vehicle(int start) { position = start;} void move(int x) { position += x ;} } Class Car extends Vehicle { int passengers; public Car(int start, int pass) { position = start; passengers =pass;} void await(Vehicle v) { if (v.position < position) then v.move(position – v.position)} else this.move(10); } Class Truck extends Vehicle { void move(int x) { if (x <= 55) then position+= x; } Class Main { Truck t = new Truck(10); Car c = new Car(10, 2); Vehicle v = c ; c.move(60); v.move(70); c.await(t); …

OO Example Class Vehicle extends object { int position; public Vehicle(int start) { position = start;} void move(int x) { position += x ;} } Class Car extends Vehicle { int passengers; public Car(int start, int pass) { position = start; passengers =pass;} void await(Vehicle v) { if (v.position < position) then v.move(position – v.position)} else this.move(10); } Class Truck extends Vehicle { void move(int x) { if (x <= 55) then position+= x; } Class Main { Truck t = new Truck(10); Car c = new Car(10, 2); Vehicle v = c ; c.move(60); v.move(70); c.await(t); …

Conclusions u Two similar techniques –Find a minimal solution to a system of equations –Find a minimal solution to a set of constraints u Next week –Mathematical foundation –Semantic foundation