1 / 44

Pointer Analysis Lecture 2

Pointer Analysis Lecture 2. G. Ramalingam Microsoft Research, India. Andersen’s Analysis. A flow-insensitive analysis computes a single points-to solution valid at all program points ignores control-flow – treats program as a set of statements

davida
Download Presentation

Pointer Analysis Lecture 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Pointer AnalysisLecture 2 G. Ramalingam Microsoft Research, India

  2. Andersen’s Analysis • A flow-insensitive analysis • computes a single points-to solution valid at all program points • ignores control-flow – treats program as a set of statements • equivalent to merging all vertices into one (and applying algorithm A) • equivalent to adding an edge between every pair of vertices (and applying algo. A) • a solution R such that R IdealMayPT(u) for every vertex u

  3. Example(Flow-Sensitive Analysis) 1 x = &a; y = x; x = &b; z = x; x = &a 2 y = x 3 x = &b 4 z = x 5

  4. Example:Andersen’s Analysis 1 x = &a; y = x; x = &b; z = x; x = &a 2 y = x 3 x = &b 4 z = x 5

  5. Andersen’s Analysis • Strong updates? • Initial state?

  6. Why Flow-Insensitive Analysis? • Reduced space requirements • a single points-to solution • Reduced time complexity • no copying • individual updates more efficient • no need for joins • number of iterations? • a cubic-time algorithm • Scales to millions of lines of code • most popular points-to analysis

  7. Andersen’s AnalysisA Set-Constraints Formulation • Compute PTx for every variable x

  8. Steensgaard’s Analysis • Unification-based analysis • Inspired by type inference • an assignment “lhs := rhs” is interpreted as a constraint that lhs and rhs have the same type • the type of a pointer variable is the set of variables it can point-to • “Assignment-direction-insensitive” • treats “lhs := rhs” as if it were both “lhs := rhs” and “rhs := lhs” • An almost-linear time algorithm • single-pass algorithm; no iteration required

  9. Example:Andersen’s Analysis 1 x = &a; y = x; y = &b; b = &c; x = &a 2 y = x 3 y = &b 4 b = &c 5

  10. Example:Steensgaard’s Analysis 1 x = &a; y = x; y = &b; b = &c; x = &a 2 y = x 3 y = &b 4 b = &c 5

  11. Steensgaard’s Analysis • Can be implemented using Union-Find data-structure • Leads to an almost-linear time algorithm

  12. Exercise x = &a; y = x; y = &b; b = &c; *x = &d;

  13. May-Point-To Analyses Ideal-May-Point-To ??? Algorithm A more efficient / less precise Andersen’s more efficient / less precise Steensgaard’s

  14. Ideal Points-To Analysis:Definition Recap • A sequence of states s1s2 … snis said to be an execution (of the program) iff • s1is the Initial-State • si| si+1for 1 <= I < n • A state s is said to be a reachable stateiff there exists some execution s1s2 … snis such that sn= s. • RS(u) = { s | (u,s) is reachable } • IdealMayPT (u) = { (p,x) | $ s Î RS(u). s(p) == x } • IdealMustPT (u) = { (p,x) | " s Î RS(u). s(p) == x }

  15. Does Algorithm A Compute The Most Precise Solution?

  16. Ideal <-> Algorithm A • Abstract away correlations between variables • relational analysis vs. • independent attribute x: &y y: &z x: &b y: &x g x: &b x: &y y: &x y: &x a x: {&y,&b} y: {&x,&z} x: &y y: &z x: &b y: &z

  17. Does Algorithm A Compute The Most Precise Solution?

  18. Is The Precise Solution Computable? • Claim: The set RS(u) of reachable concrete states (for our language) is computable. • Note: This is true for any collecting semantics with a finite state space.

  19. Computing RS(u)

  20. Precise Points-To Analysis:Decidability • Corollary: Precise may-point-to analysis is computable. • Corollary: Precise (demand) may-alias analysis is computable. • Given ptr-exp1, ptr-exp2, and a program point u, identify if there exists some reachable state at u where ptr-exp1 and ptr-exp2 are aliases. • Ditto for must-point-to and must-alias • … for our restricted language!

  21. Precise Points-To Analysis:Computational Complexity • What’s the complexity of the least-fixed point computation using the collecting semantics? • The worst-case complexity of computing reachable states is exponential in the number of variables. • Can we do better? • Theorem: Computing precise may-point-to is PSPACE-hard even if we have only two-level pointers.

  22. May-Point-To Analyses Ideal-May-Point-To more efficient / less precise Algorithm A more efficient / less precise Andersen’s more efficient / less precise Steensgaard’s

  23. Precise Points-To Analysis: Caveats • Theorem: Precise may-alias analysis is undecidable in the presence of dynamic memory allocation. • Add “x = new/malloc ()” to language • State-space becomes infinite • Digression: Integer variables + conditional-branching also makes any precise analysis undecidable.

  24. May-Point-To Analyses Ideal (with Int, with Malloc) Ideal (with Int) Ideal (with Malloc) Ideal (no Int, no Malloc) Algorithm A Andersen’s Steensgaard’s

  25. Dynamic Memory Allocation • s: x = new () / malloc () • Assume, for now, that allocated object stores one pointer • s: x = malloc ( sizeof(void*) ) • Introduce a pseudo-variable Vs to represent objects allocated at statement s, and use previous algorithm • treat s as if it were “x = &Vs” • also track possible values of Vs • allocation-site based approach • Key aspect: Vs represents a set of objects (locations), not a single object • referred to as a summary object (node)

  26. Dynamic Memory Allocation:Example 1 x = new; y = x; *y = &b; *y = &a; x = new 2 y = x 3 *y = &b 4 *y = &a 5

  27. Dynamic Memory Allocation:Object Fields • Field-sensitive analysis class Foo { A* f; B* g; } s: x = new Foo() x->f = &b; x->g = &a;

  28. Dynamic Memory Allocation:Object Fields • Field-insensitive analysis class Foo { A* f; B* g; } s: x = new Foo() x->f = &b; x->g = &a;

  29. Other Aspects • Context-sensitivity • Indirect (virtual) function calls and call-graph construction • Pointer arithmetic • Object-sensitivity

  30. Andersen’s Analysis:Further Optimizations and Extensions • Fahndrich et al., Partial online cycle elimination in inclusion constraint graphs, PLDI 1998. • Rountev and Chandra, Offline variable substitution for scaling points-to analysis, 2000. • Heintze and Tardieu, Ultra-fast aliasing analysis using CLA: a million lines of C code in a second, PLDI 2001. • M. Hind, Pointer analysis: Haven’t we solved this problem yet?, PASTE 2001. • Hardekopf and Lin, The ant and the grasshopper: fast and accurate pointer analysis for millions of lines of code, PLDI 2007. • Hardekopf and Lin, Exploiting pointer and location equivalence to optimize pointer analysis, SAS 2007. • Hardekopf and Lin, Semi-sparse flow-sensitive pointer analysis, POPL 2009.

  31. Context-Sensitivity Etc. • Liang & Harrold, Efficient computation of parameterized pointer information for interprocedural analyses. SAS 2001. • Lattner et al., Making context-sensitive points-to analysis with heap cloning practical for the real world, PLDI 2007. • Zhu & Calman, Symbolic pointer analysis revisited. PLDI 2004. • Whaley & Lam, Cloning-based context-sensitive pointer alias analysis using BDD, PLDI 2004. • Rountev et al. Points-to analysis for Java using annotated constraints. OOPSLA 2001. • Milanova et al. Parameterized object sensitivity for points-to and side-effect analyses for Java. ISSTA 2002.

  32. Applications • Compiler optimizations • Verification & Bug Finding • use in preliminary phases • use in verification itself

  33. Dynamic Memory Allocation:Summary Object Update 4 *y = &a 5

  34. Abstract Transformers:Weak/Strong Update AS[stmt] : AbsDataState -> AbsDataState AS[ *x = y ] s = s[z  s(y)] if s(x) = {z} s[z1 s(z1) s(y)] if s(x) = {z1, …, zk} [z2s(z2) s(y)] (where k > 1) … [zks(zk) s(y)]

  35. Correctness & Precision • How can we formally reason about the correctness & precision of abstract transformers? • Can we systematically derive a correct abstract transformer?

  36. Enter: The French Recipe(Abstract Interpretation) • Concrete Domain • Concrete states: C • Semantics: For every statement st, • CS[st] : C -> C • AbstractDomain • Asemi-lattice(A, ) • TransferFunctions • For every statement st, • AS[st] : A -> A • Concrete (Collecting) Domain • Asemi-lattice(2C, ) • TransferFunctions • For every statement st, • CS*[st] : 2C -> 2C a g 2Data-State 2Var x Var’

  37. Points-To Analysis(Abstract Interpretation) a(Y) = { (p,x) | exists s in Y. s(p) == x } MayPT(u) a Í a RS(u) IdealMayPT(u) 2Data-State 2Var x Var’ IdealMayPT (u) = a ( RS(u) )

  38. Approximating Transformers:Correctness Criterion c is said to be correctly approximated by a iff a(c) Ía c1 correctly approximated by a1 f c2 f# correctly approximated by a2 C A

  39. Approximating Transformers:Correctness Criterion concretization g c1 a1 f abstraction a c2 f# a2 requirement: f#(a1) ≥a (f( g(a1)) C A

  40. Concrete Transformers • CS[stmt] : Data-State -> Data-State • CS[ x = y ] s = s[x s(y)] • CS[ x = *y ] s = s[x s(s(y))] • CS[ *x = y ] s = s[s(x) s(y)] • CS[ x = null ] s = s[x null] • CS*[stmt] : 2Data-State -> 2Data-State • CS*[st] X = { CS[st]s | s Î X }

  41. Abstract Transformers • AS[stmt] : AbsDataState -> AbsDataState • AS[ x = y ] s = s[x s(y)] • AS[ x = null ] s = s[x {null}] • AS[ x = *y ] s = s[x s*(s(y))] where s*({v1,…,vn}) = s(v1) È … È s(vn) • AS[ *x = y ] s = ???

  42. Algorithm A: TranformersWeak/Strong Update x: &y y: &x z: &a g x: {&y} y: {&x,&z} z: {&a} x: &y y: &z z: &a f f# *y = &b; *y = &b; x: &b y: &x z: &a x: {&y,&b} y: {&x,&z} z: {&a,&b} x: &y y: &z z: &b a

  43. Algorithm A: TranformersWeak/Strong Update x: &y y: &x z: &a g x: {&y} y: {&x,&z} z: {&a} x: &y y: &z z: &a f f# *x = &b; *x = &b; x: &y y: &b z: &a x: {&y} y: {&b} z: {&a} x: &y y: &b z: &a a

  44. Dynamic Memory Allocation:Summary Object Update 4 *y = &a 5

More Related