1. CMPUT 680 - Compiler Design and Optimization1 CMPUT680 - Winter 2006 Topic P: Reference Analysis José Nelson Amaral http://www.cs.ualberta.ca/~amaral/courses/680

2. CMPUT 680 - Compiler Design and Optimization2 References zRyder, Barbara G., “Dimensions of Precision in Reference Analysis of Object-Oriented Programming Languages,” Compiler Construction, pp. 126-137, Warsaw, Poland, April, 2003. zShapiro, Marc and Horwitz, Susan, “Fast and Accurate Flow- Insensitive Points-To Analysis,” Symposium on Principles of Programming Languages, pp. 1-14, Paris, France, 1997. zEmami, Maryam, Ghiya, Rakesh, and Hendren, Laurie J., “Context- Sensitive Interprocedural Points-to Analysis in the Presence of Function Pointers,” Programming Language Design & Implementation, pp. 242-256, Orlando, FL, 1994. zSteensgaard, Bjarne, “Points-to Analysis in Almost Linear Time,” Symposium on Principles of Programming Languages, pp. 32-41, 1996. zLandi, William, and Ryder, Barbara G., “A Safe Approximate Algorithm for Interprocedural Pointer Aliasing, Programming Language Design & Implementation, pp. 235-248, 1992.

3. CMPUT 680 - Compiler Design and Optimization3 Motivation … [1] x=0; [2] *p = 1; [3] write(x); … Example of Optimization Problems: (1)Draw a Data Dependence Graph for statements 1-3; (2)Does definition [1] reaches statement [3]? (3)Can the constant 0 be propagated to statement [3]? (Shapiro/Horwitz, PPL97)

4. CMPUT 680 - Compiler Design and Optimization4 Motivation … [1] x=0; [2] *p = 1; [3] write(x); … There are three situations to consider: p must point to x  x=1 in [3]. p must not point to x  x=0 in [3]. p may point to x  the compiler does not know the value of x in [3]. (Shapiro/Horwitz, PPL97)

5. CMPUT 680 - Compiler Design and Optimization5 Flow-sensitivity zFlow-sensitive analysis: takes into account the order in which statements are executed; zFlow-insensitive analysis: assumes that statements can be executed in any order; (Shapiro/Horwitz, PPL97)

6. CMPUT 680 - Compiler Design and Optimization6 Context-sensitivity zContext-sensitive analysis: takes into account the fact that a function must return to the site of the most recent call; zContext-insensitive analysis:propagates information from a call site, through the called function, and back to all call sites. zA context-insensitive analysis constructs a single approximation to a procedure’s effect on all of its callers (Ruf, PLDI95). (Shapiro/Horwitz, PPL97)

7. CMPUT 680 - Compiler Design and Optimization7 Andersen’s X Steensgaard’s Analysis zBoth analysis are flow-insensitive and context- insensitive. zBoth build an alias graph (Burke, Carini, Choi, Hind, LCPC94) or a storage shape graph (Chase, Wegman, Zadeck, PLDI90). zAndersen: each node can have an arbitrary number of out-edges  each node represents one variable. zSteensgaard: each node has at most one out- edge  each node may represent more than one variable. (Shapiro/Horwitz, PPL97)

8. CMPUT 680 - Compiler Design and Optimization8 Andersen’s X Steensgaard’s (Example) a = &b; Program: Steensgaard: Andersen: S = {(a,b)} a b b a (Shapiro/Horwitz, PPL97)

9. CMPUT 680 - Compiler Design and Optimization9 Andersen’s X Steensgaard’s (Example) a = &b; b = &c; Program: Steensgaard: Andersen: S = {(a,b); (b,c)} c a b c b a (Shapiro/Horwitz, PPL97)

10. CMPUT 680 - Compiler Design and Optimization10 Andersen’s X Steensgaard’s (Example) a = &b; b = &c; a = &d; Program: Steensgaard: Andersen: S = {(a,b); (b,c)} c a b c b a (Shapiro/Horwitz, PPL97) What should happen in each analysis?

11. CMPUT 680 - Compiler Design and Optimization11 Andersen’s X Steensgaard’s (Example) a = &b; b = &c; a = &d; Program: Steensgaard: Andersen: S = {(a,b); (b,c); (a,d); (d,c)} S = {(a,b); (b,c); (a,d)} c a b d c (b,d) a (Shapiro/Horwitz, PPL97)

12. CMPUT 680 - Compiler Design and Optimization12 Andersen’s X Steensgaard’s (Example) a = &b; b = &c; a = &d; d = &e; Program: Steensgaard: Andersen: S = {(a,b); (b,c); (a,d); (d,c)} S = {(a,b); (b,c); (a,d)} c a b d c (b,d) a (Shapiro/Horwitz, PPL97) And now?

13. CMPUT 680 - Compiler Design and Optimization13 Andersen’s X Steensgaard’s (Example) a = &b; b = &c; a = &d; d = &e; Program: Steensgaard: Andersen: S = {(a,b); (b,c); (a,d); (d,c); (d,e); (b,e)} S = {(a,b); (b,c); (a,d); (d,e)} c a b d e (c,e) (b,d) a (Shapiro/Horwitz, PPL97)

14. CMPUT 680 - Compiler Design and Optimization14 Steensgaard’s Algorithm zBased on non-standard type-system. The “type” of a variable describes a set of locations possibly pointed-to by the variable. zAt initialization, each variable is described by a different type. zFast union-find structures are used to provide constant-time access to the type associated with a variable name. zProcess each statement exactly once, joining type variables as necessary to ensure that the program is well-typed. (Steensgaard, PPL96)

15. CMPUT 680 - Compiler Design and Optimization15 Comparison of Steensgaard and Andersen zFor small programs (up to 3,000 lines) both analyses are very fast. zFor some large programs, Andersen’s may take a very long time (from more than 10 to more than 100 times as long as Steensgaard’s). zFor 37 out of 61 programs (21 out of 25 “large” programs), Andersen’s points-to-set is less than half the size of Steengaard’s (thus Andersen’s is more precise). (Shapiro/Horwitz, PPL97)

16. CMPUT 680 - Compiler Design and Optimization16 Shapiro/Horwitz Algorithm 1 zAllows each node in the alias graph to have out- degree k (k is an input to the algorithm). zEach variable is assigned to one of k categories. Only merge nodes of variables in the same category. zPartition of variables into categories is an input for the algorithm: yAll variables in one category  Steensgaard yEach variable in a separate category  Andersen (Shapiro/Horwitz, PPL97)

17. Shapiro/Horwitz Algorithm 1 (Example) a = &b; a = &c; a = &d c = &d Program: Categories: {a, b, c, d} Categories: {a, b} {c, d} Categories: {a, c}, {b, d} Categories: {a, b}, {c}, {d} (b,c,d) a S = {(a, b); (a,c); (a,d); (b,b); (b,c); (b,d); (c,b); (c,c); (c,d); (d,b); (d,c), (d,d)} S = {(a, b); (a,c); (a,d); (c,c); (c,d); (d,c), (d,d)} b a (c,d) (b,d) a c S = {(a, b); (a,c); (a,d); (c,b); (c,d)} b a c d S = {(a, b); (a,c); (a,d); (c,d)} (Shapiro/Horwitz, PPL97)

18. CMPUT 680 - Compiler Design and Optimization18 Shapiro/Horwitz Algorithm 2 zInsight: Run algorithm 1 multiple times with k categories and a different category partition each time: yTrue points-to relationships are found by taking the intersection of the points-to sets computed by each run. zGoal: Select a set of runs such that for every pair of variables (x, y), there is at least one run in which x and y are in different categories. (Shapiro/Horwitz, PPL97)

19. CMPUT 680 - Compiler Design and Optimization19 Shapiro/Horwitz Algorithm 2 zSolution: R =  log k N  runs, where N is the number of variables. zAssign each variable a unique number, in base k, in the range 0 to N-1 using R digits. zUse this encoding to select the variables categories. (Shapiro/Horwitz, PPL97)

20. CMPUT 680 - Compiler Design and Optimization20 Shapiro/Horwitz Algorithm 2 (Example) (Shapiro/Horwitz, PPL97) a = &b; a = &c; a = &d c = &d Program: The program has four variables, for k=2: a 00 b 01 c 10 d 11 Categories for run 1: {a,c}, {b,d} Categories for run 2: {a,b}, {c,d} S1 = {(a, b); (a,c); (a,d); (c,b); (c,d)} Run 1: S1  S2 = {(a, b); (a,c); (a,d); (c,d)} Run 2: S2 = {(a, b); (a,c); (a,d); (c,c); (c,d); (d,c), (d,d)}

21. CMPUT 680 - Compiler Design and Optimization21 May X (Possible or Definite) Points-to Relations zPossible and definite points-to information can be important:  p = x (Emami, Ghiya, Hendren, PLDI 94) Then all previous point-to relations from y are now killed. x p y w z After the statement If p definitely points to y at this point. p y w z Before the statement

22. CMPUT 680 - Compiler Design and Optimization22 May X (Possible or Definite) Points-to Relations zPossible and definite points-to information can be important: x =  q If q definitely points to y at this point. Then the statement can be replaced by x=y. (Emami, Ghiya, Hendren, PLDI 94)

23. CMPUT 680 - Compiler Design and Optimization23 Stack-based and Heap- based aliasing zThree varieties of aliases: yAliases between variable references to the stack; yAliases between references to the heap; yAliases between two references to the same array. zAnalysis of stack-based aliases and heap- based aliases should be decoupled. (Emami, Ghiya, Hendren, PLDI 94)

24. CMPUT 680 - Compiler Design and Optimization24 Stack-based and Heap- based aliasing zStack-base analysis: yA name exist for each location of interest; yCompute an approximation of the relationship between these locations; zHeap-base analysis: yThere are no natural names for locations; yWe don’t know how many locations will exist; zSolution: consider the entire heap a single location in the stack analysis. (Emami, Ghiya, Hendren, PLDI 94)

25. CMPUT 680 - Compiler Design and Optimization25 The Reference Analysis Problem Statement zThe reference analysis problem is a generalization of alias analysis: yGiven two references p and q, is it possible that p and q may: xpoint to the same memory location? xrefer to the same object? xdispatch to the same method?

26. CMPUT 680 - Compiler Design and Optimization26 Alias Pairs zSets of alias pairs (Landi & Ryder PLDI93): two variable references may be aliased if they may refer to the same memory location. q After statement p=q, the following alias pairs are created:  p,  q ,  p->next, q->next ,  p->next->next, q->next->next , …

27. CMPUT 680 - Compiler Design and Optimization27 Points-to Abstraction zCreate an abstract representation of the stack: xEach real stack location that is involved in a points-to relationship is represented by exactly one named abstract location; xEach named abstract location represents one or more real stack locations. (Emami, Ghiya, Hendren, PLDI 94) y x loc i loc j Abstract Locations Real Locations loc k

28. CMPUT 680 - Compiler Design and Optimization28 Abstract Stack Location zAn abstract stack location corresponds to one of this: yThe name of a local variable, global variable, or parameter. yA symbolic name that represents a location not in the scope of the procedure under analysis. yThe symbolic name heap. (Emami, Ghiya, Hendren, PLDI 94)

29. CMPUT 680 - Compiler Design and Optimization29 Definitely Points-to zAn abstract location x definitely points to abstract location y, noted (x, y, D), for a given invocation context, if: yx and y each represent exactly one real location in that context; and ythe real location corresponding to x contains the address of the real location y. (Emami, Ghiya, Hendren, PLDI 94)

30. CMPUT 680 - Compiler Design and Optimization30 Possibly Points-to zAn abstract location x possibly points to abstract location y, noted (x, y, P), for a given invocation context, if: yIt is possible that one of the real locations corresponding to x contains the address of one of the real locations represented by y. (Emami, Ghiya, Hendren, PLDI 94)

31. CMPUT 680 - Compiler Design and Optimization31 Safe Approximation zLet S be the points-to set at point p. zConsider all pairs of real locations loc i and loc j. Let x be the abstract location of loc i and y be the abstract location of loc j. y x loc i loc j Abstract Locations Real Locations (Emami, Ghiya, Hendren, PLDI 94)

32. CMPUT 680 - Compiler Design and Optimization32 Safe Approximation zS is a safe approximation at p if: yS contains (x,y,D) or (x,y,P) when loc i points to loc j on all valid execution paths to p. yS contains (x,y,P) when loc i points to loc j in some, but not all, execution paths to p. yIf S contains (x,y,D) then loc i must point to loc j in all paths to p. y x loc i loc j Abstract Locations Real Locations ? (Emami, Ghiya, Hendren, PLDI 94)

33. CMPUT 680 - Compiler Design and Optimization33 Safety and Precision zAn approximation is unsafe if: yA real points-to relationship is not in S; yA spurious definite points-to relation is in S; zThe following approximation is safe, just not very precise: yEvery abstract location possibly points-to every other abstract location. (Emami, Ghiya, Hendren, PLDI 94)

34. CMPUT 680 - Compiler Design and Optimization34 L-locations and R-locations zProblem: Given the input points-to set S in of an statement S, generate its output points-to set S out. zSolution: yCompute an abstract representation of the locations represented in the left-hand side (L-locations) and in the right-hand side (R-locations) of S. yNotation: x(x,D): abstract location x is definitely in the set x(x,P): abstract location x is possibly in the set

35. CMPUT 680 - Compiler Design and Optimization35 L-locations and R-locations (example)  q = w S input = {(q,y,D); (y,w,P); (y,z,P); (w,v,D)} S output = ? (Emami, Ghiya, Hendren, PLDI 94) L-locations(*q) = {(x,d) | (q,x,d)  S} L-locations(*q) = ? q y w z Before the statement v R-locations(w) = {(x,d) | (w,x,d)  S} R-locations(w) = ?

36. CMPUT 680 - Compiler Design and Optimization36 L-locations and R-locations (example)  q = w S input = {(q,y,D); (y,w,P); (y,z,P); (w,v,D)} S output = ? (Emami, Ghiya, Hendren, PLDI 94) L-locations(*q) = {(x,d) | (q,x,d)  S} R-locations(w) = {(x,d) | (w,x,d)  S} L-locations(*q) = {(y,D)} R-locations(w) = {(v,D)} q y w z Before the statement v S change = {(p,x,D) | (p,P)  L-locations(*q)  (p,x,D)  S input } = ? S gen = {(p,x,d1  d2) | (p,d1)  L-locations(*q)  (x,d2)  R-locations(w)} = ? S kill = {(p,x,d) | (p,D)  L-locations(*q)  (p,x,d)  S input } = ? The clause in green above is not in the original paper, but it is necessary.

37. CMPUT 680 - Compiler Design and Optimization37 L-locations and R-locations (example)  q = w S input = {(q,y,D); (y,w,P); (y,z,P); (w,v,D)} S output = ? (Emami, Ghiya, Hendren, PLDI 94) L-locations(*q) = {(x,d) | (q,x,d)  S} R-locations(w) = {(x,d) | (w,x,d)  S} L-locations(*q) = {(y,D)} R-locations(w) = {(v,D)} q y w z Before the statement v S kill = {(p,x,d) | (p,D)  L-locations(*q)  (p,x,d)  S input } = {(y,w,P),(y,z,P)} S change = {(p,x,D) | (p,P)  L-locations(*q)  (p,x,D)  S input } = { } S gen = {(p,x,d1  d2) | (p,d1)  L-locations(*q)  (x,d2)  R-locations(w)} = {(y,v,D)} The clause in green above is not in the original paper, but it is necessary.

38. CMPUT 680 - Compiler Design and Optimization38 L-locations and R-locations (example)  q = w S input = {(q,y,D); (y,w,P); (y,z,P); (w,v,D)} S output = ? (Emami, Ghiya, Hendren, PLDI 94) L-locations(*q) = {(y,D)} R-locations(w) = {(v,D)} q y w z Before the statement v S kill = {(y,w,P),(y,z,P)} S change = { } S gen = {(y,v,D)} S inputchanged = (S input - S change )  {(p,x,D)  S change } =

39. CMPUT 680 - Compiler Design and Optimization39 L-locations and R-locations (example)  q = w S input = {(q,y,D); (y,w,P); (y,z,P); (w,v,D)} S output = ? (Emami, Ghiya, Hendren, PLDI 94) L-locations(*q) = {(y,D)} R-locations(w) = {(v,D)} q y w z Before the statement v S kill = {(y,w,P),(y,z,P)} S change = { } S gen = {(y,v,D)} S inputchanged = (S input - S change )  {(p,x,D)  S change } = S input

40. CMPUT 680 - Compiler Design and Optimization40 L-locations and R-locations (example)  q = w S input = {(q,y,D); (y,w,P); (y,z,P); (w,v,D)} S output = ? (Emami, Ghiya, Hendren, PLDI 94) L-locations(*q) = {(y,D)} R-locations(w) = {(v,D)} q y w z Before the statement v S kill = {(y,w,P),(y,z,P)} S change = { } S gen = {(y,v,D)} S inputchanged = (S input - S change )  {(p,x,D)  S change } = S input S output = (S inputchanged - S kill )  S gen = ?

41. CMPUT 680 - Compiler Design and Optimization41 L-locations and R-locations (example)  q = w S input = {(q,y,D); (y,w,P); (y,z,P); (w,v,D)} S output = {(q,y,D); (w,v,D); (y,v,D)} (Emami, Ghiya, Hendren, PLDI 94) L-locations(*q) = {(y,D)} R-locations(w) = {(v,D)} q y w z Before the statement v S kill = {(y,w,P),(y,z,P)} S change = { } S gen = {(y,v,D)} S inputchanged = S input S output = (S inputchanged - S kill )  S gen = ? q y w z After the statement v

42. CMPUT 680 - Compiler Design and Optimization42 Invocation Graph zPrograms without recursion: Invocation graph built with a depth-first traversal of the call structure, starting with main. zPrograms with recursion: Invocation structure not known at compile time. Invocation graph approximates all unrollings of recursions. (Emami, Ghiya, Hendren, PLDI 94)

43. CMPUT 680 - Compiler Design and Optimization43 Invocation Graph (examples) main() { … g(); } g() { … f(); … } main g f g f main() { … f(); } f() { g(); if (y) f(); } g() { if (e) f(); } f-R g f-A main f-A: An approximate node where a stored approximation for the function should be used (instead of an evaluation of the function call). f-R: A recursive node where a fixed-point computation must be performed. (Emami, Ghiya, Hendren, PLDI 94)

44. CMPUT 680 - Compiler Design and Optimization44 Advantages of using an Invocation Graph zSeparates inter-procedural analysis from calling contexts. zCreates places to deposit context- sensitive information for subsequent analysis. zCreates places to store IN/OUT pairs summarizing the effects of a function call. zAllows simple compositional fixed-point computations for recursions. (Emami, Ghiya, Hendren, PLDI 94)

45. CMPUT 680 - Compiler Design and Optimization45 Inter-procedural Context- sensitivy analysis f() { … g(a); } g(x) { … } Caller Callee Map Process Unmap Process Function Analysis Special care in the Map process: Formal parameters and global variables that are multi- level pointers. Invisible variables: formals and globals that point to variables outside of the scope of the callee. (Emami, Ghiya, Hendren, PLDI 94)

46. CMPUT 680 - Compiler Design and Optimization46 Inter-procedural Context- sensitivy analysis f() { … g(a); } g(x) { … } Caller Callee Map Process Unmap Process Function Analysis Solutions to the Map process: Multi-level pointers: apply the mapping process recursively to all levels of pointer type. Invisible variables: generate special symbolic names to represent each level of indirection of pointer variables (see paper for details). (Emami, Ghiya, Hendren, PLDI 94)

47. CMPUT 680 - Compiler Design and Optimization47 Approximate and Recursive Nodes zA recursive node f-R stores an input, an output, and a list of pending inputs. yThe input and output pairs approximate the effect of the call to f. yThe fixed-point computation generalizes the stored input and output until it summarizes all invocations of f. (Emami, Ghiya, Hendren, PLDI 94)

48. CMPUT 680 - Compiler Design and Optimization48 Function Pointer zWhen a function is called through a function pointer a set of functions may be called. zSome safe approximations for this set are: yAll the functions in the program. yAll functions which have had their addresses taken. yThe set of functions that the pointer can point to at the program point where the call is. (Emami, Ghiya, Hendren, PLDI 94)

49. CMPUT 680 - Compiler Design and Optimization49 A cyclic dependence zTo obtain the points-to set for the function pointer, we need to perform points-to analysis. zBut points-to analysis needs the invocation graph of the program because it is context sensitive and inter- procedural. zThe solution is to construct the invocation graph while performing points-to analysis. (Emami, Ghiya, Hendren, PLDI 94)

50. CMPUT 680 - Compiler Design and Optimization50 Handling Function Pointers 1.Build the invocation graph, leaving it incomplete where a function pointer call is encountered. 2.Perform points-to analysis using the incomplete invocation graph. 3.When an indirect call through a function pointer is encountered, find the set P of all functions it can point to according to current information. 4.Update the invocation graph to indicate that the indirect call may call any function in P. 5.Analyze each function f  P in the context of the call --- while analyzing f assume that the function pointer definitely points to f. 6.Merge the output points-to sets of all functions in P. (Emami, Ghiya, Hendren, PLDI 94)

51. CMPUT 680 - Compiler Design and Optimization51 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } S = ? (Emami, Ghiya, Hendren, PLDI 94)

52. CMPUT 680 - Compiler Design and Optimization52 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } main fp foobar S = {(fp,foo,P); (fp,bar,P); (pc,c,D)} S = ? fp foo bar pc c (Emami, Ghiya, Hendren, PLDI 94)

53. CMPUT 680 - Compiler Design and Optimization53 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } main fp foobar S = {(fp,foo,P); (fp,bar,P); (pc,c,D)} S = {(fp,foo,D); (pc,c,D)} fp foo bar pc c (Emami, Ghiya, Hendren, PLDI 94)

54. CMPUT 680 - Compiler Design and Optimization54 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } main fp foo-Rbar S = {(fp,foo,P); (fp,bar,P); (pc,c,D)} S = {(fp,foo,D); (pc,c,D)} fp foo-A S = ? fp foo bar pc c (Emami, Ghiya, Hendren, PLDI 94)

55. CMPUT 680 - Compiler Design and Optimization55 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } main fp foo-Rbar S = {(fp,foo,P); (fp,bar,P); (pc,c,D)} S = {(fp,foo,D); (pc,c,D)} fp foo-A S = {(fp,foo,D); (pc,c,D); (pa,a,D)} S = ? fp foo bar pc c pa a (Emami, Ghiya, Hendren, PLDI 94)

56. CMPUT 680 - Compiler Design and Optimization56 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } main fp foo-Rbar S = {(fp,foo,P); (fp,bar,P); (pc,c,D)} S = {(fp,foo,D); (pc,c,D)} fp foo-A S = {(fp,foo,D); (pc,c,D); (pa,a,D)} S = {(fp,bar,D); (pc,c,D)} S = ? fp foo bar pc c pa a (Emami, Ghiya, Hendren, PLDI 94)

57. CMPUT 680 - Compiler Design and Optimization57 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } main fp foo-Rbar S = {(fp,foo,P); (fp,bar,P); (pc,c,D)} S = {(fp,foo,D); (pc,c,D)} fp foo-A S = {(fp,foo,D); (pc,c,D); (pa,a,D)} S = {(fp,bar,D); (pc,c,D)} S = {(fp,bar,D); (pc,c,D); (pb,b,D)} fp foo bar pc c pa a pb b (Emami, Ghiya, Hendren, PLDI 94)

58. CMPUT 680 - Compiler Design and Optimization58 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } main fp foo-Rbar S = {(fp,foo,P); (fp,bar,P); (pc,c,D)} S = {(fp,foo,D); (pc,c,D)} fp foo-A S = {(fp,foo,D); (pc,c,D); (pa,a,D)} S = {(fp,bar,D); (pc,c,D)} S = {(fp,bar,D); (pc,c,D); (pb,b,D)} fp foo bar pc c pa a pb b S = ? (Emami, Ghiya, Hendren, PLDI 94)

59. CMPUT 680 - Compiler Design and Optimization59 Function Pointers (Example) int a, b, c; int *pa, *pb, *pc; int (*fp)(); main() { … pc = &c; if (cond) fp = foo; else fp = bar; fp(); } foo() { … pa = &a; if (cond) fp(); } bar() {... pb = &b; } main fp foo-Rbar S = {(fp,foo,P); (fp,bar,P); (pc,c,D)} S = {(fp,foo,D); (pc,c,D)} fp foo-A S = {(fp,foo,D); (pc,c,D); (pa,a,D)} S = {(fp,bar,D); (pc,c,D)} S = {(fp,bar,D); (pc,c,D); (pb,b,D)} fp foo bar pc c pa a pb b S = {(fp,foo,P); (fp,bar,P); (pc,c,D); (pa,a,P); (pb,b,P)} (Emami, Ghiya, Hendren, PLDI 94)