This preview shows pages 1–10. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
Unformatted text preview: Course Outline Introduction Controlflow analysis Dataflow analysis and abstract interpretation Sparse analysis Adding indirection (pointers) Adding functions Type and constraintbased analysis Ben Hardekopf () CS 290C Program Analysis Fall 2011 1 / 43 Section Outline Pointers Extending Lingo Pointer Analysis DFA Redux SSA Redux Sparse Pointer Analysis Ben Hardekopf () CS 290C Program Analysis Fall 2011 2 / 43 Extending Lingo with Pointers Syntax n ∈ Z b ∈ B x ∈ V ariable ⊕ ∈ Op ::= +    *  /  <  < =  =  !=  &&   e ∈ Exp ::= n  b  x  ! x  e ⊕ e rhs ∈ Rhs ::= e  ref x  new type c ∈ Cmd ::= c ; c  x := rhs  ! x := rhs  skip  input x  while ( e ) do { c }  if ( e ) then { c } else { c } type ::= integer  boolean  ref type p ∈ Prog ::= c Ben Hardekopf () CS 290C Program Analysis Fall 2011 3 / 43 Example Example (Lingo with Pointers) z := ref x ; w := ref a ; if (_) then { !z := ref a ; y := ref b } else { x := ref b ; y := w } ; !x := !y Variables can now be either integers, booleans, or references. Variables are strongly typed—a variable is either an integer variable, a boolean variable, or a reference variable Reference variables are initialized to null Ben Hardekopf () CS 290C Program Analysis Fall 2011 4 / 43 Effect on Program Analysis Example (Program Fragment) . . . x := 5 ; y := x+1 ; !z := 3 ; x := y+2 What can we say about: Reaching definitions? Available expressions? Constant and range propagation? Ben Hardekopf () CS 290C Program Analysis Fall 2011 5 / 43 The Fundamental Problem We’ve added a powerful and disruptive element to the language— indirection . This has important consequences: We can no longer reason about program behavior based solely on syntax (e.g., syntactically ’ !x := 2 ’ says nothing about what is being modified) We have to worry about indirect data access (hidden information flow) and indirect control flow (e.g., function pointers) Ben Hardekopf () CS 290C Program Analysis Fall 2011 6 / 43 The Fundamental Problem We’ve added a powerful and disruptive element to the language— indirection . This has important consequences: We can no longer reason about program behavior based solely on syntax (e.g., syntactically ’ !x := 2 ’ says nothing about what is being modified) We have to worry about indirect data access (hidden information flow) and indirect control flow (e.g., function pointers) Most modern languages use indirection in some form: Java references, OOP virtual methods, closures, . . . C/C++, Java, C#, Python, Perl, Ruby, Javascript, Scheme, Haskell, OCaml, Scala, . . . Ben Hardekopf () CS 290C Program Analysis Fall 2011 6 / 43 Section Outline Pointers Extending Lingo Pointer Analysis DFA Redux SSA Redux Sparse Pointer Analysis Ben Hardekopf () CS 290C Program Analysis Fall 2011 7 / 43 Pointer Analysis The goal of pointer analysis is to resolve the indirection introduced by using pointers. It is fundamental to any sort of nontrivial program analysis—if you can’t resolve indirection, then you can’t understand...
View
Full
Document
This note was uploaded on 12/27/2011 for the course CMPSC 290a taught by Professor Vandam during the Fall '09 term at UCSB.
 Fall '09
 Vandam

Click to edit the document details