1 Control Flow Analysis Mooly Sagiv Tel Aviv University 640-6706 Textbook Chapter 3

Slides:



Advertisements
Similar presentations
Objects and Classes David Walker CS 320. Advanced Languages advanced programming features –ML data types, exceptions, modules, objects, concurrency,...
Advertisements

Continuing Abstract Interpretation We have seen: 1.How to compile abstract syntax trees into control-flow graphs 2.Lattices, as structures that describe.
Type Checking, Inference, & Elaboration CS153: Compilers Greg Morrisett.
Context-Sensitive Interprocedural Points-to Analysis in the Presence of Function Pointers Presentation by Patrick Kaleem Justin.
Interprocedural Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday
Compilation 2011 Static Analysis Johnni Winther Michael I. Schwartzbach Aarhus University.
Pointer Analysis – Part I Mayur Naik Intel Research, Berkeley CS294 Lecture March 17, 2009.
3-Valued Logic Analyzer (TVP) Tal Lev-Ami and Mooly Sagiv.
Some Properties of SSA Mooly Sagiv. Outline Why is it called Static Single Assignment form What does it buy us? How much does it cost us? Open questions.
1 How to transform an analyzer into a verifier. 2 OUTLINE OF THE LECTURE a verification technique which combines abstract interpretation and Park’s fixpoint.
Semantic Analysis Chapter 4. Role of Semantic Analysis Following parsing, the next two phases of the "typical" compiler are – semantic analysis – (intermediate)
Recap 1.Programmer enters expression 2.ML checks if expression is “well-typed” Using a precise set of rules, ML tries to find a unique type for the expression.
Winter Compiler Construction T7 – semantic analysis part II type-checking Mooly Sagiv and Roman Manevich School of Computer Science Tel-Aviv.
1 Programming Languages (CS 550) Lecture Summary Functional Programming and Operational Semantics for Scheme Jeremy R. Johnson.
Functional Programming. Pure Functional Programming Computation is largely performed by applying functions to values. The value of an expression depends.
Compiling Object Oriented Programs Mooly Sagiv Chapter
Lecture 02 – Structural Operational Semantics (SOS) Eran Yahav 1.
Objects and Classes David Walker CS 320. Advanced Languages advanced programming features –ML data types, exceptions, modules, objects, concurrency,...
1 Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications.
Program analysis Mooly Sagiv html://
Denotational Semantics Syntax-directed approach, generalization of attribute grammars: –Define context-free abstract syntax –Specify syntactic categories.
Control Flow Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
1 Iterative Program Analysis Part I Mooly Sagiv Tel Aviv University Textbook: Principles of Program.
Program analysis Mooly Sagiv html://
1 Iterative Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Programming Language Semantics Mooly SagivEran Yahav Schrirber 317Open space html://
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.
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 =
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
Functional programming: LISP Originally developed for symbolic computing First interactive, interpreted language Dynamic typing: values have types, variables.
1 Program Analysis Systematic Domain Design Mooly Sagiv Tel Aviv University Textbook: Principles.
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.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
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.
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
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.
Imperative Programming
1 Iterative Program Analysis Abstract Interpretation Mooly Sagiv Tel Aviv University Textbook:
Interpretation Environments and Evaluation. CS 354 Spring Translation Stages Lexical analysis (scanning) Parsing –Recognizing –Building parse tree.
Formal Semantics Chapter Twenty-ThreeModern Programming Languages, 2nd ed.1.
A Third Look At ML Chapter NineModern Programming Languages, 2nd ed.1.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Chapter 3 Part II Describing Syntax and Semantics.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
1 Shape Analysis via 3-Valued Logic Mooly Sagiv Tel Aviv University Shape analysis with applications Chapter 4.6
1 Combining Abstract Interpreters Mooly Sagiv Tel Aviv University
Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications Chapter.
1 FP Foundations, Scheme In Text: Chapter Chapter 14: FP Foundations, Scheme Mathematical Functions Def: A mathematical function is a mapping of.
1 Iterative Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program.
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.
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.
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.
Functional Programming
Textbook: Principles of Program Analysis
Combining Abstract Interpreters
Compiler Design 18. Object Oriented Semantic Analysis (Symbol Tables, Type Checking) Kanat Bolazar March 30, 2010.
Iterative Program Analysis Abstract Interpretation
Another example: constant prop
FP Foundations, Scheme In Text: Chapter 14.
6.001 SICP Variations on a Scheme
Presentation transcript:

1 Control Flow Analysis Mooly Sagiv Tel Aviv University Textbook Chapter Assign 3 (11/7)

2 Goals u Understand the problem of Control Flow Analysis –in Functional Languages –In Object Oriented Languages –Function Pointers u Learn Constraint Based Program Analysis Technique –General –Usage for Control Flow Analysis –Algorithms –Systems u Similarities between Problems &Techniques

3 Outline u A Motivating Example (OO) u The Control Flow Analysis Problem u Set Constraints u Solving Constraints u Adding Dataflow information u Adding Context Information u Back to the Motivating Example

4 A Motivating Example class Vehicle Object { int position = 10; void move (int x1) { position = position + x1 ;}} class Car extends Vehicle { int passengers; 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 x2) { if (x2 < 55) position += x2; }} void main { Car c; Truck t; Vehicle v1; new c; new t; v1 := c; c.passangers := 2; c.move(60); v1.move(70); c.await(t) ;}

5 A Motivating Example class Vehicle Object { int position = 10; static void move (Vehicle this1 {Car}, int x1) { position = position + x1 ;}} class Car extends Vehicle { int passengers; static void await(Car this2 {Car}, Vehicle v {Truck}) { if (v.position < position) then v.move(v, position - v.position); else this2.move(this2, 10); }} class Truck extends Vehicle { static void move(Truck this3 {Truck}, int x2) { if (x2 < 55) position += x2; }} void main { Car c; Truck t; Vehicle v1; new c; new t; v1 := c; c.passangers := 2; c.move(c, 60); v1.move(v1, 70); c.await(c, t) ;}

6 The Control Flow Analysis (CFA) 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 u The Dynamic Dispatch Problem

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

8 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)

9 The Language FUN u Notations –e  Exp // expressions (or labeled terms) –t  Term // terms (or unlabeled terms) –f, x  Var // variables –c  Const // Constants –op  Op // Binary operators –l  Lab // Labels u Abstract Syntax –e ::= t l –t ::= c | x | fn x  e // function definition | fun f x  e // recursive function definition | e 1 e 2 // function applications | if e 0 then e 1 else e 2 | let x = e 1 in e 2 | e 1 op e 2

10 A Simple Example ((fn x  x 1 ) 2 (fn y  y 3 ) 4 ) 5

11 Factorial (let fact = fun f n  (if (n = 0) 1 then 1 2 else ((n 3 * (f 4 (n 5 – 1 6 ) 7 ) 8 ) 9 ) 10

12 An Example which Always Loops (let g = fun f x  (f 1 (fn y  y 2 ) 3 ) 4 ) 5 (g 6 (fn z  z 7 ) 8 ) 9 ) 10

13 The 0-CFA Problem u Control flow analysis without contexts u Compute for every program a pair (C,  ) where: –C is the abstract cache associating abstract values with labeled program points –  is the abstract environment associating abstract values with program variables u Abstract Values –v  Val = P(Term) // Abstract values –   Env = Var  Val // Abstract environment –C  Cache =Lab  Val // Abstract Cache –For function application (t 1 l1 t 2 l2 ) l C(l1) determines the function that can be applied –Formally …

14 Possible Solutions for ((fn x  x 1 ) 2 (fn y  y 3 ) 4 ) 5

15 (let g = fun f x  (f 1 (fn y  y 2 ) 3 ) 4 ) 5 (g 6 (fn z  z 7 ) 8 ) 9 Shorthands sf  fun f x  (f 1 (fn y  y 2 ) 3 ) 4 id y  fn y  y 2 id z  fn z  z 7 C(1) = {sf} C(2) = {}C(3) = {id y } C(4) = {} C(5) = {sf}C(6) = {sf} C(7) = {}C(8) = {id z }C(9) = {} C(10) = {}  (x) = {id y, id z }  (y) = {}  (z) = {}

16 Relationship to Dataflow Analysis u Expressions are side effect free –no entry/exit u A single environment u Represents information at different points via maps u A single value for all occurrences of a variable u Function applications act similar to assignments –“Definition” - Function abstraction is created –“Use”- Function is applied

17 A Formal Specification of 0-CFA u A Boolean function  define when a solution is acceptable u (C,  )  e means that (C,  ) is acceptable for the expression e u Define  by structural induction on e u Every function is analyzed once u Every acceptable solution is sound (conservative) u Many acceptable solutions u Generate a set of constraints u Obtain the least acceptable solution by solving the constraints

18 Solving 0-CFA (1) u Define a concrete semantics u Define a Galois connection between the concrete and the abstract semantics u Define abstract meaning for statements u Show local soundness u Implement Chaotic iterations

19 Solving 0-CFA (2) u Generate a system of set of constraints –lhs  rhs –{t}  rhs’  lhs  rhs (conditional constraint) u Show that any solution to the set of constraints is sound u Find the minimal solution u Systems for finding the minimal solution exist u Applicable to different programming languages

20 Set Constraints u A set of rules of the form: –lhs  rhs –{t}  rhs’  lhs  rhs (conditional constraint) –lhs, rhs, rhs’ are »terms »C(l) »  (x) u The least solution (C,  ) can be found iteratively –start with empty sets –add terms when needed u Efficient cubic graph based solution

21 Syntax Directed Constraint Generation (Part I) C *  c l  = {} C *  x l  = {r (x)  C (l)} C *  (fn x  e) l  = C *  e   { {fn x  e}  C(l)} C *  (fun f x  e) l  = C *  e   { {fun f x  e}  C(l)}  {{fun f x  e}  r( f)} C *  (t 1 l1 t 2 l2 ) l  = C *  t 1 l1   C *  t 2 l2   {{t}  C(l)  C (l2)  r (x) | t=fn x  t 0 l0  Term * }  {{t}  C(l)  C (l0)  C (l) | t=fn x  t 0 l0  Term * }  {{t}  C(l)  C (l2)  r (x) | t=fun x  t 0 l0  Term * }  {{t}  C(l)  C (l0)  C (l) | t=fun x  t 0 l0  Term * }

22 Syntax Directed Constraint Generation (Part II) C *  (if t 0 l0 then t 1 l1 else t 2 l2 ) l  = C *  t 0 l0   C *  t 1 l1   C *  t 2 l2   {C(l1)  C (l)}  {C(l2)  C (l)} C *  (let x = t 1 l1 in t 2 l2 ) l  = C *  t 1 l1   C *  t 2 l2   {C(l1)  r (x)}  {C(l2)  C(l)} C *  (t 1 l1 op t 2 l2 ) l  = C *  t 1 l1   C *  t 2 l2 

23 Set Constraints for ((fn x  x 1 ) 2 (fn y  y 3 ) 4 ) 5

24 Iterative Solution to the Set Constraints for ((fn x  x 1 ) 2 (fn y  y 3 ) 4 ) 5

25 Graph Based Solution to Constraint Systems u Construct a directed graph –Nodes »Set variables –Edges »u  v u The set variable v may depend on u u Iteratively traverse the graph –Every operation adds a term –Must terminate u Read the solution from the graph

26 The Constraint Graph for 0-CFA u Nodes –C(l) –r(x) u Edges –p1  p2 »Construct p1  p2 –{t}  p  p1  p2 »Construct p1  p2 »Construct p  p2 u Dependencies –D[v] »The set of terms that must be included in v

27 WL :=  For all nodes v: D[v] :=  E[v] :=  For all constraints c: case c  {t}  p: add(p, {t}) case c  p1  p2: E[p1] := E[p1]  {c} case c={t}  p  p1  p2 E[p] := E[p]  {c} E[p1] := E[p1]  {c} procedure add(q, s) if (s  D(q)) then D[q] : = D[q]  s WL := WL  {q} while WL  do select and remove an element v from WL for all c  E[v] do case c  p1  p2: add(p2, D[p1]) case c={t}  p  p1  p2 if t  D[p] then add(p2, D[p1])

28 Adding Data Flow Information u Dataflow values can affect control flow analysis u Example (let f = (fn x  (if (x 1 > 0 2 ) 3 then (fn y  y 4 ) 5 else (fn z  5 6 ) 7 ) 8 ) 9 in ((f ) ) 14 ) 15

29 Adding Data Flow Information u Add a finite set of “abstract” values per program Data u Update Val = P(Term  Data) –   Env = Var  Val // Abstract environment –C  Cache - Lab  Val // Abstract Cache u Generate extra constraints for data u Obtained a more precise solution u A special of case of product domain (4.4) u The combination of two analyses may be more precise than both u For some programs may even be more efficient

30 Adding Dataflow Information (Sign Analysis) u Sign analysis u Add a finite set of “abstract” values per program Data = {P, N, TT, FF} u Update Val = P(Term  Data) u d c is the abstract value that represents a constant c – d 3 = {p} –d -7 = {n} –d true = {tt} –d false = {ff} u Every operator is conservatively interpreted

31 Syntax Directed Constraint Generation (Part I) C *  c l  = d c  C (l)} C *  x l  = {r (x)  C (l)} C *  (fn x  e) l  = C *  e   { {fn x  e}  C(l)} C *  (fun f x  e) l  = C *  e   { {fun f x  e}  C(l)}  {{fun f x  e}  r( f)} C *  (t 1 l1 t 2 l2 ) l  = C *  t 1 l1   C *  t 2 l2   {{t}  C(l)  C (l2)  r (x) | t=fn x  t 0 l0  Term * }  {{t}  C(l)  C (l0)  C (l) | t=fn x  t 0 l0  Term * }  {{t}  C(l)  C (l2)  r (x) | t=fun x  t 0 l0  Term * }  {{t}  C(l)  C (l0)  C (l) | t=fun x  t 0 l0  Term * }

32 Syntax Directed Constraint Generation (Part II) C *  (if t 0 l0 then t 1 l1 else t 2 l2 ) l  = C *  t 0 l0   C *  t 1 l1   C *  t 2 l2   {d t  C (l0)  C(l1)  C (l)}  {d f  C (l0)  C(l2)  C (l)} C *  (let x = t 1 l1 in t 2 l2 ) l  = C *  t 1 l1   C *  t 2 l2   {C(l1)  r (x)}  {C(l2)  C(l)} C *  (t 1 l1 op t 2 l2 ) l  = C *  t 1 l1   C *  t 2 l2   {C(l1) op C(l2)  C(l)}

33 Adding Context Information u The analysis does not distinguish between different occurrences of a variable (Monovariant analysis) u Example (let f = (fn x  x 1 ) 2 in ((f 3 f 4 ) 5 (fn y  y 6 ) 7 ) 8 ) 9 u Source to source can help (but may lead to code explosion) u Example rewritten let f1 = fn x1  x1 in let f2 = fn x2  x2 in (f1 f2) (fn y  y )

34 Simplified K-CFA u Records the last k dynamic calls (for some fixed k) u Similar to the call string approach u Remember the context in which expression is evaluated u Val is now P(Term)  Contexts –   Env = Var  Contexts  Val –C  Cache - Lab  Contexts  Val

35 1-CFA u (let f = (fn x  x 1 ) 2 in ((f 3 f 4 ) 5 (fn y  y 6 ) 7 ) 8 ) 9 u Contexts – [] - The empty context –[5] The application at label 5 –[8] The application at label 8 u Polyvariant Control Flow C(1, [5]) =  (x, 5)= C(2, []) = C(3, []) =  (f, []) = ({(fn x  x 1 )}, [] ) C(1, [8]) =  (x, 8)= C(7, []) = C(8, []) = C(9, []) = ({(fn y  y 6 )}, [] )

36 A Motivating Example class Vehicle Object { int position = 10; static void move (Vehicle this1 {Car}, int x1) { position = position + x1 ;}} class Car extends Vehicle { int passengers; static void await(Car this2 {Car}, Vehicle v {Truck}) { if (v.position < position) then v.move(v, position - v.position); else this2.move(this2, 10); }} class Truck extends Vehicle { static void move(Truck this3 {Truck}, int x2) { if (x2 < 55) position += x2; }} void main { Car c; Truck t; Vehicle v1; new c; new t; v1 := c; c.passangers := 2; c.move(c, 60); v1.move(v1, 70); c.await(c, t) ;}

37 class Vehicle Object { int position = 10; static void move (Vehicle t1, int x1) { position = position + x1 ;}} class Car extends Vehicle { int passengers; static void await(Car t2, Vehicle v) { if (v.position < position) then v.move(v, position - v.position); else t2.move(t2, 10); }} class Truck extends Vehicle { static void move(Truck t3, int x2) { if (x2 < 55) position += x2; }} void main { Car c; Truck t; Vehicle v1; new c; new t; v1 := c; c.passangers := 2; c.move(c, 60); v1.move(v1, 70); c.await(c, t) ;} {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2)

38 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) WL c t

39 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) WL c t c c c t

40 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) WL c t c c c t t

41 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) WL c t c c c t t

42 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) WL c t c c c t t

43 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) WL c t c c c t t

44 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) WL c t c c c t t

45 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) WL c t c c c t t

46 {V}  cl(v)  cl(v)  cl(t1) {T}  cl(v)  cl(v)  cl(t3) {C}  cl(v)  cl(v)  cl(t1) {C}  cl(t2)  cl(t2)  cl(t1) {C}  cl(c) {T}  cl(t) cl(c)  cl(v1) {C}  cl(c)  cl(c)  cl(t1) {V}  cl(v1)  cl(v1)  cl(t1) {T}  cl(v1)  cl(v1)  cl(t3) {C}  cl(v1)  cl(v1)  cl(t1) {C}  cl(c)  cl(t)  cl(v) {C}  cl(c)  cl(c)  cl(t2) cl(c) cl(t1) cl(t2) cl(t3) cl(v) cl(t) cl(v1) c t c c c t t

47 A Motivating Example class Vehicle Object { int position = 10; static void move (Vehicle this1 {Car}, int x1) { position = position + x1 ;}} class Car extends Vehicle { int passengers; static void await(Car this2 {Car}, Vehicle v {Truck}) { if (v.position < position) then v.move(v, position - v.position); else this2.move(this2, 10); }} class Truck extends Vehicle { static void move(Truck this3 {Truck}, int x2) { if (x2 < 55) position += x2; }} void main { Car c; Truck t; Vehicle v1; new c; new t; v1 := c; c.passangers := 2; c.move(c, 60); v1.move(v1, 70); c.await(c, t) ;}

48 Missing Material u Efficient Cubic Solution to Set Constraints u Experimental results for OO u Operational Semantics for FUN (3.2.1) u Defining acceptability of set constraints u Using general lattices as Dataflow values instead of powersets (3.5.2) u Lower-bounds –Decidability of JOP –Polynomiality

49 Conclusions u Set constraints are quite useful –A Uniform syntax –Can even deal with pointers u But semantic foundation is still based on abstract interpretation u Techniques used in functional and imperative (OO) programming are similar u Control and data flow analysis are related