Advanced Compiler Techniques LIU Xianhua School of EECS, Peking University Pointer Analysis.

Slides:



Advertisements
Similar presentations
Dataflow Analysis for Datarace-Free Programs (ESOP 11) Arnab De Joint work with Deepak DSouza and Rupesh Nasre Indian Institute of Science, Bangalore.
Advertisements

Data-Flow Analysis II CS 671 March 13, CS 671 – Spring Data-Flow Analysis Gather conservative, approximate information about what a program.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) SSA Guo, Yao.
P3 / 2004 Register Allocation. Kostis Sagonas 2 Spring 2004 Outline What is register allocation Webs Interference Graphs Graph coloring Spilling Live-Range.
1 CS 201 Compiler Construction Lecture 3 Data Flow Analysis.
Context-Sensitive Interprocedural Points-to Analysis in the Presence of Function Pointers Presentation by Patrick Kaleem Justin.
Compilation 2011 Static Analysis Johnni Winther Michael I. Schwartzbach Aarhus University.
ECE 454 Computer Systems Programming Compiler and Optimization (I) Ding Yuan ECE Dept., University of Toronto
Pointer Analysis – Part I Mayur Naik Intel Research, Berkeley CS294 Lecture March 17, 2009.
Control-Flow Graphs & Dataflow Analysis CS153: Compilers Greg Morrisett.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
Flow insensitive pointer analysis: fixed S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) Pointer Analysis.
Worst case complexity of Andersen *x = y x abc y def x abc y def Worst case: N 2 per statement, so at least N 3 for the whole program. Andersen is in fact.
1 CS 201 Compiler Construction Lecture Interprocedural Data Flow Analysis.
Flow-Insensitive Points-to Analysis with Term and Set Constraints Presentation by Kaleem Travis Patrick.
School of EECS, Peking University “Advanced Compiler Techniques” (Fall 2011) Dataflow Analysis Introduction Guo, Yao Part of the slides are adapted from.
Program Representations. Representing programs Goals.
Parallel Inclusion-based Points-to Analysis Mario Méndez-Lojo Augustine Mathew Keshav Pingali The University of Texas at Austin (USA) 1.
Semi-Sparse Flow-Sensitive Pointer Analysis Ben Hardekopf Calvin Lin The University of Texas at Austin POPL ’09 Simplified by Eric Villasenor.
Interprocedural analysis © Marcelo d’Amorim 2010.
Common Sub-expression Elim Want to compute when an expression is available in a var Domain:
Recap from last time We were trying to do Common Subexpression Elimination Compute expressions that are available at each program point.
Feedback: Keep, Quit, Start
Next Section: Pointer Analysis Outline: –What is pointer analysis –Intraprocedural pointer analysis –Interprocedural pointer analysis (Wilson & Lam) –Unification.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Advanced Compilers CMPSCI 710.
Interprocedural pointer analysis for C We’ll look at Wilson & Lam PLDI 95, and focus on two problems solved by this paper: –how to represent pointer information.
Flow insensitivity and imprecision If you ignore flow, then you lose precision. main() { x := &y;... x := &z; } Flow insensitive analysis tells us that.
Previous finals up on the web page use them as practice problems look at them early.
Range Analysis. Intraprocedural Points-to Analysis Want to compute may-points-to information Lattice:
Intraprocedural Points-to Analysis Flow functions:
From last time S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l t S1 p L2 l t S1 p S2 l t.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Advanced Compilers CMPSCI 710.
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.
Comparison Caller precisionCallee precisionCode bloat Inlining context-insensitive interproc Context sensitive interproc Specialization.
Recap from last time: live variables x := 5 y := x + 2 x := x + 1 y := x y...
Reps Horwitz and Sagiv 95 (RHS) Another approach to context-sensitive interprocedural analysis Express the problem as a graph reachability query Works.
Machine-Independent Optimizations Ⅰ CS308 Compiler Theory1.
Schedule Midterm out tomorrow, due by next Monday Final during finals week Project updates next week.
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)
Pointer analysis. Pointer Analysis Outline: –What is pointer analysis –Intraprocedural pointer analysis –Interprocedural pointer analysis Andersen and.
Symbolic Path Simulation in Path-Sensitive Dataflow Analysis Hari Hampapuram Jason Yue Yang Manuvir Das Center for Software Excellence (CSE) Microsoft.
Procedure Optimizations and Interprocedural Analysis Chapter 15, 19 Mooly Sagiv.
Precision Going back to constant prop, in what cases would we lose precision?
Advanced Compiler Techniques LIU Xianhua School of EECS, Peking University Inter-procedural Analysis.
Mark Marron IMDEA-Software (Madrid, Spain) 1.
Type Systems CS Definitions Program analysis Discovering facts about programs. Dynamic analysis Program analysis by using program executions.
Fast Points-to Analysis for Languages with Structured Types Michael Jung and Sorin A. Huss Integrated Circuits and Systems Lab. Department of Computer.
Mark Marron 1, Deepak Kapur 2, Manuel Hermenegildo 1 1 Imdea-Software (Spain) 2 University of New Mexico 1.
ESEC/FSE-99 1 Data-Flow Analysis of Program Fragments Atanas Rountev 1 Barbara G. Ryder 1 William Landi 2 1 Department of Computer Science, Rutgers University.
Dataflow Analysis for Concurrent Programs using Datarace Detection Ravi Chugh, Jan W. Voung, Ranjit Jhala, Sorin Lerner LBA Reading Group Michelle Goodstein.
Using Types to Analyze and Optimize Object-Oriented Programs By: Amer Diwan Presented By: Jess Martin, Noah Wallace, and Will von Rosenberg.
Pointer Analysis Survey. Rupesh Nasre. Aug 24, 2007.
1 Becoming More Effective with C++ … Day Two Stanley B. Lippman
Pointer Analysis – Part I CS Pointer Analysis Answers which pointers can point to which memory locations at run-time Central to many program optimization.
D A C U C P Speculative Alias Analysis for Executable Code Manel Fernández and Roger Espasa Computer Architecture Department Universitat Politècnica de.
1PLDI 2000 Off-line Variable Substitution for Scaling Points-to Analysis Atanas (Nasko) Rountev PROLANGS Group Rutgers University Satish Chandra Bell Labs.
Pointer Analysis CS Alias Analysis  Aliases: two expressions that denote the same memory location.  Aliases are introduced by:  pointers  call-by-reference.
Inter-procedural analysis
Pointer Analysis Lecture 2
Interprocedural Analysis Chapter 19
CSC D70: Compiler Optimization Pointer Analysis
Topic 10: Dataflow Analysis
Pointer Analysis Lecture 2
Pointer analysis.
Pointer Analysis Jeff Da Silva Sept 20, 2004 CARG.
CSE P 501 – Compilers SSA Hal Perkins Autumn /31/2019
Pointer analysis John Rollinson & Kaiyuan Li
Presentation transcript:

Advanced Compiler Techniques LIU Xianhua School of EECS, Peking University Pointer Analysis

 Outline : What is pointer analysis Intraprocedural pointer analysis Interprocedural pointer analysis  Andersen and Steensgaard New Directions 2 “Advanced Compiler Techniques”

Pointer and Alias Analysis  Aliases : two expressions that denote the same memory location.  Aliases are introduced by : pointers call - by - reference array indexing C unions 3 “Advanced Compiler Techniques”

Useful for What? 4 Improve the precision of analysis that require knowing what is modified or referenced ( eg const prop, CSE … ) Eliminate redundant loads / stores and dead stores. Parallelization of code –can recursive calls to quick_sort be run in parallel? Yes, provided that they reference distinct regions of the array. Identify objects to be tracked in error detection tools x := *p;... y := *p; // replace with y := x? *x :=...; // is *x dead? x.lock();... y.unlock(); // same object as x? “Advanced Compiler Techniques”

Challenges for Pointer Analysis  Complexity : huge in space and time compare every pointer with every other pointer at every program point potentially considering all program paths to that point  Scalability vs accuracy trade - off different analyses motivated for different purposes many useful algorithms ( adds to confusion )  Coding corner cases pointer arithmetic (* p ++), casting, function pointers, long - jumps  Whole program? most algorithms require the entire program library code? optimizing at link - time only? 5 “Advanced Compiler Techniques”

Kinds of Alias Information 6 Points - to information ( must or may versions ) –at program point, compute a set of pairs of the form p -> x, where p points to x. –can represent this information in a points - to graph - Less precise, more efficient Alias pairs –at each program point, compute the set of all pairs ( e 1, e 2 ) where e 1 and e 2 must / may reference the same memory. –More precise, less efficient Storage shape analysis –at each program point, compute an abstract description of the pointer structure. p x y zp “Advanced Compiler Techniques”

Intraprocedural Points-to Analysis  Want to compute may - points - to information  Lattice : Domain : 2 { x -> y | x ∈ Var, Y ∈ Var } Join : set union BOT : Empty TOP : { x -> y | x ∈ Var, Y ∈ Var } 7 “Advanced Compiler Techniques”

Flow Functions(1) 8 x := a + b in out F x := a+b (in) = x := k in out F x := k (in) = in – {x, *} “Advanced Compiler Techniques”

Flow Functions(2) 9 x := &y in out F x := &y (in) = x := y in out F x := y (in) = in – {x, *} U {(x,z) | (y,z) ∈ in } in – {x, *} U {(x, y)} “Advanced Compiler Techniques”

Flow Functions(3) 10 *x := y in out F *x := y (in) = x := *y in out F x := *y (in) = in – {x, *} U {(x, t) | (y,z) ∈ in && (z,t) ∈ in } In – {} U {(a, b) | (x,a) ∈ in && (y,b) ∈ in } “Advanced Compiler Techniques”

Intraprocedural Points-to Analysis 11 Flow functions : “Advanced Compiler Techniques”

Pointers to Dynamically Allocated Memory 12 Handle statements of the form : x := new T One idea : generate a new variable each time the new statement is analyzed to stand for the new location : “Advanced Compiler Techniques”

Example 13 l := new Cons p := l t := new Cons *p := t p := t “Advanced Compiler Techniques”

Example Solved 14 l := new Cons p := l t := new Cons *p := t p := t l p V1 l p tV2 l p V1 t V2 l t V1 p V2 l t V1 p V2 l t V1 p V2V3 l t V1 p V2V3 l t V1 p V2V3 “Advanced Compiler Techniques”

What Went Wrong? 15 Lattice was infinitely tall ! Instead, we need to summarize the infinitely many allocated objects in a finite way. –introduce summary nodes, which will stand for a whole class of allocated objects. For example : For each new statement with label L, introduce a summary node loc L, which stands for the memory allocated by statement L. Summary nodes can use other criterion for merging. “Advanced Compiler Techniques”

Example Revisited & Solved 16 S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 Iter 1Iter 2Iter 3 “Advanced Compiler Techniques”

Example Revisited & Solved 17 S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 Iter 1Iter 2Iter 3 “Advanced Compiler Techniques”

Array Aliasing and Pointers to Arrays  Array indexing can cause aliasing : a[i] aliases b[j] if :  a aliases b and i = j  a and b overlap, and i = j + k, where k is the amount of overlap.  Can have pointers to elements of an array p := &a[i];...; p++;  How can arrays be modeled? Could treat the whole array as one location. Could try to reason about the array index expressions : array dependence analysis. 18 “Advanced Compiler Techniques”

Fields  Can summarize fields using per field summary for each field F, keep a points - to node called F that summarizes all possible values that can ever be stored in F  Can also use allocation sites for each field F, and each allocation site S, keep a points - to node called ( F, S ) that summarizes all possible values that can ever be stored in the field F of objects allocated at site S. 19 “Advanced Compiler Techniques”

Summary  We just saw : intraprocedural points - to analysis handling dynamically allocated memory handling pointers to arrays  But, intraprocedural pointer analysis is not enough. Sharing data structures across multiple procedures is one of the big benefits of pointers : instead of passing the whole data structures around, just pass pointers to them ( eg C pass by reference ). So pointers end up pointing to structures shared across procedures. If you don ’ t do an interproc analysis, you ’ ll have to make conservative assumptions functions entries and function calls. 20 “Advanced Compiler Techniques”

Conservative Approximation on Entry 21 Say we don ’ t have interprocedural pointer analysis. What should the information be at the input of the following procedure : global g; void p(x,y) {... } xyg “Advanced Compiler Techniques”

Conservative Approximation on Entry 22 Here are a few solutions : xyg locations from alloc sites prior to this invocation global g; void p(x,y) {... } They are all very conservative ! We can try to do better. x,y,g & locations from alloc sites prior to this invocation “Advanced Compiler Techniques”

Interprocedural Pointer Analysis  Main difficulty in performing interprocedural pointer analysis is scaling  One can use a bottom - up summary based approach ( Wilson & Lam 95), but even these are hard to scale 23 “Advanced Compiler Techniques”

Example Revisited 24 Cost : –space : store one fact at each prog point –time : iteration S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l t S1 p L2 l t S1 p S2 l t S1 p S2 l t S1 p S2 l t L1 p L2 l t S1 p S2 l t S1 p S2 Iter 1Iter 2Iter 3 “Advanced Compiler Techniques”

New Idea: Store One Dataflow Fact  Store one dataflow fact for the whole program  Each statement updates this one dataflow fact use the previous flow functions, but now they take the whole program dataflow fact, and return an updated version of it.  Process each statement once, ignoring the order of the statements  This is called a flow - insensitive analysis. 25 “Advanced Compiler Techniques”

Flow Insensitive Pointer Analysis 26 S1: l := new Cons p := l S2: t := new Cons *p := t p := t “Advanced Compiler Techniques”

Flow Insensitive Pointer Analysis 27 S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 “Advanced Compiler Techniques”

Flow Sensitive vs. Insensitive 28 S1: l := new Cons p := l S2: t := new Cons *p := t p := t l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 Flow-sensitive SolnFlow-insensitive Soln l t S1 p S2 “Advanced Compiler Techniques”

What Went Wrong?  What happened to the link between p and S 1 ? Can ’ t do strong updates anymore ! Need to remove all the kill sets from the flow functions.  What happened to the self loop on S 2 ? We still have to iterate ! 29 “Advanced Compiler Techniques”

Flow Insensitive Pointer Analysis: Fixed 30 S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l t S1 p L2 l t S1 p S2 l t S1 p S2 l t S1 p S2 l t L1 p L2 l t S1 p S2 Iter 1Iter 2Iter 3 l t S1 p S2 Final result This is Andersen ’ s algorithm ’94 “Advanced Compiler Techniques”

Flow Insensitive Loss of Precision 31 S1: l := new Cons p := l S2: t := new Cons *p := t p := t l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 Flow-sensitive SolnFlow-insensitive Soln l t S1 p S2 “Advanced Compiler Techniques”

Flow Insensitive Loss of Precision 32 Flow insensitive analysis leads to loss of precision ! main() { x := &y;... x := &z; } Flow insensitive analysis tells us that x may point to z here! However : – uses less memory ( memory can be a big bottleneck to running on large programs ) – runs faster “Advanced Compiler Techniques”

Worst Case Complexity of Andersen 33 *x = y x abc y def x abc y def Worst case : N 2 per statement, so at least N 3 for the whole program. Andersen is in fact O ( N 3 ) “Advanced Compiler Techniques”

New Idea: One Successor Per Node 34 Make each node have only one successor. This is an invariant that we want to maintain. x a,b,c y d,e,f *x = y x a,b,c y d,e,f “Advanced Compiler Techniques”

More General Case for *x = y 35 x *x = y y “Advanced Compiler Techniques”

More General Case for *x = y 36 x *x = y yxyxy “Advanced Compiler Techniques”

More General Cases 37 x x = *y y Handling: x = *y “Advanced Compiler Techniques”

More General Cases 38 x x = *y yxyxy Handling: x = *y “Advanced Compiler Techniques”

More General Cases 39 x x = y y x = &y xy Handling: x = y (what about y = x?) Handling: x = &y “Advanced Compiler Techniques”

More General Cases 40 x x = y yxyxy x = &y xyx y,… xy Handling: x = y (what about y = x?) Handling: x = &y get the same for y = x “Advanced Compiler Techniques”

Our Favorite Example, Once More! 41 S1: l := new Cons p := l S2: t := new Cons *p := t p := t “Advanced Compiler Techniques”

Our Favorite Example, Once More! 42 S1: l := new Cons p := l S2: t := new Cons *p := t p := t l S1 t S2 p l S1 l p l t S2 p l S1,S2 tp l S1 t S2 p 4 5 “Advanced Compiler Techniques”

Flow Insensitive Loss of Precision 43 S1: l := new Cons p := l S2: t := new Cons *p := t p := t l t S1 p S2 l t S1 p S2 l t S1 p S2 l t S1 p S2 Flow-sensitive Subset-based Flow-insensitive Subset-based l t S1 p S2 l S1,S2 tp Flow-insensitive Unification- based “Advanced Compiler Techniques”

Another Example 44 bar() { i := &a; j := &b; foo(&i); foo(&j); // i pnts to what? *i :=...; } void foo(int* p) { printf(“%d”,*p); } “Advanced Compiler Techniques”

Another Example 45 bar() { i := &a; j := &b; foo(&i); foo(&j); // i pnts to what? *i :=...; } void foo(int* p) { printf(“%d”,*p); } i a j b p i a i a j b i a j b p i,j a,b p “Advanced Compiler Techniques”

Steensgaard vs. Andersen 46 Consider assignment p = q, i. e., only p is modified, not q  Subset - based Algorithms Andersen ’ s algorithm is an example Add a constraint : Targets of q must be subset of targets of p Graph of such constraints is also called “ inclusion constraint graphs ” Enforces unidirectional flow from q to p  Unification - based Algorithms Steensgaard is an example Merge equivalence classes : Targets of p and q must be identical Assumes bidirectional flow from q to p and vice - versa “Advanced Compiler Techniques”

Steensgaard & Beyond  A well engineered implementation of Steensgaard ran on Word 97 (2.1 MLOC ) in 1 minute.  One Level Flow ( Das PLDI 00) is an extension to Steensgaard that gets more precision and runs in 2 minutes on Word “Advanced Compiler Techniques”

Analysis Sensitivity  Flow - insensitive What may happen ( on at least one path ) Linear - time  Flow - sensitive Consider control flow ( what must happen ) Iterative data - flow : possibly exponential  Context - insensitive Call treated the same regardless of caller “ Monovariant ” analysis  Context - sensitive Reanalyze callee for each caller “ Polyvariant ” analysis More sensit ivity more accura cy, but more expens e 48

Inter-procedural Analysis  What do we do if there are function calls? x1 = &a y1 = &b swap(x1, y1) x2 = &a y2 = &b swap(x2, y2) swap (p1, p2) { t1 = *p1; t2 = *p2; *p1 = t2; *p2 = t1; }

Two Approaches  Context - sensitive approach : treat each function call separately just like real program execution would problem : what do we do for recursive functions?  need to approximate  Context - insensitive approach : merge information from all call sites of a particular function in effect, inter - procedural analysis problem is reduced to intra - procedural analysis problem  Context - sensitive approach is obviously more accurate but also more expensive to compute

Context Insensitive Approach x1 = &a y1 = &b swap(x1, y1) x2 = &a y2 = &b swap(x2, y2) swap (p1, p2) { t1 = *p1; t2 = *p2; *p1 = t2; *p2 = t1; }

Context Sensitive Approach x1 = &a y1 = &b swap(x1, y1) x2 = &a y2 = &b swap(x2, y2) swap (p1, p2) { t1 = *p1; t2 = *p2; *p1 = t2; *p2 = t1; } swap (p1, p2) { t1 = *p1; t2 = *p2; *p1 = t2; *p2 = t1; }

Binary Decision Diagram (BDD) 53

BDD-Based Pointer Analysis  Use a BDD to represent transfer functions – encode procedure as a function of its calling context – compact and efficient representation  Perform context - sensitive, inter - procedural analysis – similar to dataflow analysis – but across the procedure call graph  Gives accurate results – and scales up to large programs 54

Which Pointer Analysis Should I Use? Hind & Pioli, ISSTA, Aug  Compared 5 algorithms (4 flow - insensitive, 1 flow - sensitive ): Any address ( single points - to set ) Steensgaard Andersen Burke ( like Andersen, but separate solution per procedure ) Choi et al. ( flow - sensitive ) 55 “Advanced Compiler Techniques”

Which Pointer Analysis Should I Use? (cont’d)  Metrics 1. Precision : number of alias pairs 2. Precision of important optimizations : MOD / REF, REACH, LIVE, flow dependences, constant prop. 3. Efficiency : analysis time / memory, optimization time / memory  Benchmarks 23 C programs, including some from SPEC benchmarks 56 “Advanced Compiler Techniques”

Summary of Results Hind & Pioli, ISSTA, Aug Precision : Steensgaard much better than Any - Address (6 x on average ) Andersen / Burke significantly better than Steensgaard ( about 2 x ) Choi negligibly better than Andersen / Burke 2. MOD / REF precision : Steensgaard much better than Any - Address (2.5 x on average ) Andersen / Burke significantly better than Steensgaard (15%) Choi very slightly better than Andersen / Burke (1%) 57

“Advanced Compiler Techniques” Summary of Results (cont’d) 3. Analysis cost : Any - Address, Steensgaard extremely fast Andersen / Burke about 30 x slower Choi about 2.5 x slower than Andersen / Burke 4. Total cost ( analysis + optimizations ): Steensgaard, Burke are 15% faster than Any - Address ! Andersen is as fast as Any - Address ! Choi only about 9% slower 58

History of Points-to Analysis from Ryder and Rayside

“Advanced Compiler Techniques” Haven’t We Solved This Problem Yet? From [ Hind, 2001]:  Past 21 years : at least 75 papers and nine Ph. D. theses published on pointer analysis 60

“Advanced Compiler Techniques” Many Publications… 61

“Advanced Compiler Techniques” So Which Pointer Analysis is Best?  Comparisons between algorithms difficult Size of points - to sets inadequate  Model heap as one blob = one object for all heap pointers !  Trade - offs unclear Faster pointer analysis can mean more objects = more time for client analysis More precise analysis can reduce client analysis time !  Idea : use client to drive pointer analyzer… 62

“Advanced Compiler Techniques” New Approaches  Speculative Pointer Analysis Traditional analysis is conservative, to guarantee correctness.  Applications : program transformation, program optimization Some application does not require 100% correctness.  Most important : applicability and usability 63

“Advanced Compiler Techniques” Speculative Pointer Analysis (SPA) – An Example int a,b; int *p; p = &a; for (i=0…1000){ *p = 5; p = &b; } pa pa pb pb a b p pb 64

“Advanced Compiler Techniques” Purpose of SPA  Optimize pointer location set widths in loop bodies speculatively  Remove unlikely or infrequent location sets Improves ability to manage access statically in our context Improves precision for the typical case 65

“Advanced Compiler Techniques” Summary of SPA  Traditional pointer analysis Based on compile time provable information Stops analysis if that cannot be guaranteed Used in many performance optimization techniques  Speculative pointer and distance analysis Always completes analysis without restrictions Extracts precise information for our purposes Targets compiler - enabled memory systems 66

“Advanced Compiler Techniques” Probability Based Pointer Analysis (ASPLOS’06)  Silvia & Steffan, U Toronto  Define a probability for a points - to relation  Use matrix calculation to compute the resulting probability for each pointer 67

Conventional Pointer Analysis 68 *a = ~ ~ = *b *a = ~~ = *b  Do pointers a and b point to the same location? Do this for every pair of pointers at every program point Pointer Analysis Definitely Not Definitely Maybe optimize “Advanced Compiler Techniques”

Probabilistic Pointer Analysis (PPA) 69 *a = ~ ~ = *b *a = ~~ = *b PPA With what probability p, do pointers a and b point to the same location? Do this for every pair of pointers at every program point p p = 0.0 p p = 1.0 p 0.0 < p < 1.0 optimize “Advanced Compiler Techniques”

PPA Research Objectives  Accurate points - to probability information at every static pointer dereference  Scalable analysis Goal : The entire SPEC integer benchmark suite  Understand scalability / accuracy tradeoff through flexible static memory model  Improve our understanding of programs 70

“Advanced Compiler Techniques” Algorithm Design Choices  Fixed Bottom Up / Top Down Approach Linear transfer functions ( for scalability ) One - level context and flow sensitive  Flexible Edge profiling ( or static prediction ) Safe ( or unsafe ) Field sensitive ( or field insensitive ) 71

“Advanced Compiler Techniques” Traditional Points-To Graph int x, y, z, *b = &x; void foo(int *a) { if(…) b = &y; if(…) a = &z; else(…) a = b; while(…) { x = *a; … } y UND a z b x = pointer = pointed at Definitely Maybe = =  Results are inconclusive 72

“Advanced Compiler Techniques” Probabilistic Points-To Graph int x, y, z, *b = &x; void foo(int *a) { if(…) b = &y; if(…) a = &z; else(…) a = b; while(…) { x = *a; … } y UND a z b x  0.1 taken (edge profile)  0.2 taken (edge profile) = pointer = pointed at p = <p< 1.0 = = p  Results provide more information 73

“Advanced Compiler Techniques” Summary  Pointer Analysis Overview Andersen ’ s Algorithm Steensgaard ’ s Algorithm New Directions  Next Time Parallelism & Locality Analysis 74