# Liveness-Based Pointer Analysis

←

**Page content transcription**

If your browser does not render page correctly, please read the page content below

Liveness-Based Pointer Analysis Uday P. Khedker1, Alan Mycroft2 , and Prashant Singh Rawat1 1 Indian Institute of Technology Bombay {uday,prashantr}@cse.iitb.ac.in 2 University of Cambridge Alan.Mycroft@cl.cam.ac.uk Abstract. Precise flow- and context-sensitive pointer analysis (FCPA) is gen- erally considered prohibitively expensive for large programs; most tools relax one or both of the requirements for scalability. We argue that precise FCPA has been over-harshly judged—the vast majority of points-to pairs calculated by ex- isting algorithms are never used by any client analysis or transformation because they involve dead variables. We therefore formulate a FCPA in terms of a joint points-to and liveness analysis which we call L-FCPA. We implemented a naive L-FCPA in GCC-4.6.0 using linked lists. Evaluation on SPEC2006 showed sig- nificant increase in the precision of points-to pairs compared to GCC’s analysis. Interestingly, our naive implementation turned out to be faster than GCC’s anal- ysis for all programs under 30kLoC. Further, L-FCPA showed that fewer than 4% of basic blocks had more than 8 points-to pairs. We conclude that the usable points-to information and the required context information is small and sparse and argue that approximations (e.g. weakening flow or context sensitivity) are not only undesirable but also unnecessary for performance. 1 Introduction Interprocedural data flow analysis extends an analysis across procedure boundaries to incorporate the effect of callers on callees and vice-versa. In order to compute precise information, such an analysis requires flow sensitivity (associating different informa- tion with distinct control flow points) and context sensitivity (computing different in- formation for different calling contexts). The efficiency and scalability of such an anal- ysis is a major concern and sacrificing precision for scalability is a common trend be- cause the size of information could be large. Hence precise flow- and context-sensitive pointer analysis (FCPA) is considered prohibitively expensive and most methods em- ploy heuristics that relax one or both of the requirements for efficiency. We argue that the precision and efficiency in pointer analysis need not conflict and may actually be synergistic. We demonstrate this by formulating a liveness-based flow- and context-sensitive points-to analysis (referred to as L-FCPA): points-to information is computed only for the pointers that are live and the propagation of points-to informa- tion is restricted to live ranges of respective pointers. We use strong liveness to discover pointers that are directly used or are used in defining pointers that are strongly live. This includes the effect of dead code elimination and is more precise than simple liveness. Fig. 1 provides a motivating example. Since main prints z, it is live at O12 (exit of node 12) and hence at I12 (entry of node 12). Thus w becomes live at O9 and hence at

main() Sm 1 { x = &y; Let In /On denote the entry/exit point of Sp 8 x = &y 2 node n. Let (a, b) at a program point u de- w = &x; 9 z=w note that a points-to b at u. Then, p(); print z; w = &x 3 – z is live at O9 which make w live at } 10 c2 O3 . Hence we should compute (w, x) c1 4 in node 3 and thereby (z, x) in node 9. p() { if (...) This causes x to be live because of ∗z 11 r2 { z = w; in node 12. Hence we should compute r1 5 (x, y) in node 2 and (z, y) in node 12. p(); 12 z = ∗z z = ∗z; print z 6 – (w, x) and (x, y) should not be propa- } Ep 13 gated to nodes 5, 6, 7 because w, x are } not live in these nodes. Em 7 Fig. 1. A motivating example for L-FCPA and its supergraph representation. The solid and dashed edges represent intraprocedural and interprocedural control flow respectively. O3 resulting in the points-to pair (w, x) at O3 . This pair reaches I9 giving the pair (z, x) at O9 . When this information reaches I12 , x becomes live. This liveness is propagated to O2 giving the pair (x, y). Finally, we get the pair (z, y) at O12 . Figures 6 and 7 give fuller detail of the solution after formulating L-FCPA. Here we highlight the following: – Use of liveness: points-to pairs are computed only when the pointers become live. – Sparse propagation: pairs (x, y) and (w, x) are not propagated beyond the call to p in main because they are not live. – Flow sensitivity: points-to information is different for different control flow points. – Context sensitivity: (z, x) holds only for the inner call to p made from within p but not for the outer call to p made from the main procedure. Thus in spite of z being live at I6 , (z, x) is not propagated to I6 but (z, y) is. We achieve this using a data flow framework (Section 3) that employs an interdependent formulation for discovering strongly live pointer variables and their pointees. We com- pute must-points-to information from may-points-to information without fixed-point computation. Section 4 uses value-based termination of call strings for precise interpro- cedural analysis without having to compute a prohibitively large number of call strings. Section 5 discusses how heap locations, stack locations, and records are handled. After Section 6 (related work), Section 7 details experimental results which suggest that the traditional FCPA is non-scalable because it computes and stores (a) an order of magni- tude more points-to pairs than can ever be used by a client analysis (e.g. pairs for dead pointers), and (b) a prohibitively large number of redundant contexts. 2 Background A procedure p is represented by a control-flow graph (CFG). It has a unique entry node Sp with no predecessor and a unique exit node Ep with no successor; every node n is reachable from Sp , and Ep is reachable from every n. At the interprocedural level, a 2

Forward Analysis (Out n depends on Inn ) Backward Analysis (Inn depends on Out n ) l BI n = Sp Inn = fn (Out n ) Inn = Out m otherwise lBI n = Ep Out n = m∈pred(n) Inm otherwise Out n = fn (Inn ) m∈succ(n) Fig. 2. Typical data flow equations for some procedure p. program is represented by a supergraph (e.g. in Fig. 1) which connects the CFGs by interprocedural edges. A call to procedure p at call site i is split into a call node ci and a return node ri with a call edge ci → Sp and a return edge Ep → ri . Formulating Data Flow Analysis. Data flow variables Inn and Out n associate data flow information with CFG node n (respectively for its entry point In and exit point On ); they must satisfy data flow equations (Fig. 2) involving node transfer functions fn . Data flow values are taken from a meet-semilattice (meet represents confluence and the initial data flow value is ⊤). The boundary information BI represents the data flow infor- mation at ISp for forward analysis and OEp for backward analysis. Its value is governed by the semantics of the information being discovered. Interprocedural analysis elimi- nates the need for a fixed BI (except for arguments to the main procedure) by computing it from the calling contexts during the analysis. Flow-insensitive approaches disregard intraprocedural control flow for efficiency; they effectively treat the flow-equations as inequations (⊑) and constrain all the Inn to be equal (and similarly all the Out n ). Flow- sensitive analyses honour control flow and keep the data flow information separate for each program point. Iterative methods solve data flow equations by repeatedly refining the values at each program point n starting from a conservative initialisation of ⊤; there are various strategies for this including round robin sweeps and work list methods. The most precise data flow information at the intraprocedural level is the Meet over Paths (MoP) solution [1, 2]. However, in general, an algorithm can at best compute the Maximum Fixed Point (MFP) solution [1, 2]; however this is possible only if it is flow-sensitive. For distributive frameworks, e.g. live-variable analysis, MFP and MoP coincide; for non-distributive frameworks such as points-to analysis, they may differ. Pointer Analysis. Points-to relations are computed by identifying locations corre- sponding to the left- and right-hand sides of a pointer assignment and taking their cartesian product [3, 4]. The points-to pairs of locations that are modified are removed. May-points-to information at n contains the points-to pairs that hold along some path reaching n whereas must-points-to information contains the pairs that hold along every path reaching n (hence a pointer can have at most one pointee) [4]. Fig. 3 exempli- fies flow-sensitive points-to analysis. By contrast an inclusion-based (Andersen) flow- insensitive analysis [5] associates (p, r), (p, s), (q, r), (r, s), (s, r) with all program points while the weaker equality-based (Steensgaard) analysis [6] further adds (q, s). Interprocedural Data Flow Analysis. A supergraph contains control flow paths which violate nestings of matching call return pairs (e.g. 1-2-3-4-8-13-11 for the supergraph in 3

May analysis Must analysis q = &r 1 Node Inn Out n Inn Out n 1 ∅ (q, r) ∅ (q, r) p=q 2 (p, r), (p, s), (p, r), (q, r), 2 (q, r) (p, r), (q, r) (q, r), (r, s), (s, r) (r, s), (s, r) p = ∗p 3 5 (p, r), (q, r), (p, s), (q, r), (p, r), 3 (q, r) s=q (r, s), (s, r) (r, s), (s, r) (q, r) (p, s), (q, r), (p, s), (q, r), (p, s), print p 4 4 (p, s), (q, r) (r, s), (s, r) (r, s), (s, r) (q, r) (p, r), (q, r), (p, r), (q, r), (p, r), (p, r), (q, r), 5 (r, s), (s, r) (r, s), (s, r) (q, r) (s, r) r = &s 6 (p, r), (p, s), (p, r), (p, s), 6 (q, r), (q, r), (r, s) (q, r), (r, s), (s, r) (q, r), (r, s), (s, r) p = ∗p 7 (p, r), (p, s), (p, r), (p, s), (q, r), 7 (q, r), (r, s) (q, r), (r, s), (s, r) (q, r), (r, s), (s, r) (r, s) Fig. 3. An example of flow-sensitive intraprocedural points-to analysis. Fig. 1). Such paths correspond to infeasible contexts. An interprocedurally valid path is a feasible execution path containing a legal sequence of call and return edges. A context-sensitive analysis retains sufficient information about calling contexts to distinguish the data flow information reaching a procedure along different call chains. This restricts the analysis to interprocedurally valid paths. A context-insensitive analy- sis does not distinguish between valid and invalid paths, effectively merging data flow information across calling contexts. Recursive procedures have potentially infinite con- texts, yet context-sensitive analysis is decidable for data flow frameworks with finite lattices and it is sufficient to maintain a finite number of contexts for such frameworks. Since this number is almost always impractically large, most context-sensitive methods limit context sensitivity in some way. At the interprocedural level, the most precise data flow information is the Meet over Interprocedurally Valid Paths (IMoP) and the Maximum Fixed Point over Interprocedu- rally Valid Paths (IMFP) [7–9]. For computing IMFP, an interprocedural method must be fully flow and context sensitive. Relaxing flow (context) sensitivity admits invalid intraprocedural (interprocedural) paths; since no path is excluded, the computed in- formation is provably safe but could be imprecise. Some examples of fully flow- and context-sensitive methods are: the graph reachability method [8] and the more general functional and full call-strings methods [7]. We use a variant of the full call-strings method [10] and compute the IMFP giving the most precise computable solution for pointer analysis; the loss of precision due to non-distributivity is inevitable. Call-Strings Method [1, 7, 10]. This is a flow- and context-sensitive approach that embeds context information in the data flow information and ensures the validity of interprocedural paths by maintaining a history of calls in terms of call strings. A call string at node n is a sequence c1 c2 . . . ck of call sites corresponding to unfinished calls at n and can be viewed as a snapshot of the call stack. Call-string construction is gov- erned by interprocedural edges. Let σ be a call string reaching procedure p. For an intraprocedural edge m → n in p, σ reaches n. For a call edge ci → Sq where ci be- 4

longs to p, call string σci reaches Sq . For a return edge Ep → rj where rj belongs to a caller of p there are two cases: if σ = σ ′ cj then σ ′ reaches rj ; otherwise σ and its data flow value is not propagated to rj . This ensures that data flow information is only propagated to appropriate call sites. In a backward analysis, the call string grows on traversing a return edge and shrinks on traversing a call edge. The interprocedural data flow information at node n is a function from call strings to data flow values. Merging (⊓) the data flow values associated with all call strings reaching n gives the overall data flow value at n. The original full call-strings method [7] used a pre-calculated length resulting in an impractically large number of call strings. We use value-based termination of call-string construction [10]. For forward flow, call strings are partitioned at Sp based on equality of their data flow values, only one call string per partition is propagated, and all call strings of the partition are regenerated at Ep (and the other way round for backward flows). This constructs only the relevant call strings (i.e. call strings with distinct data flow values) reducing the number of call strings significantly. For finite data flow lat- tices, we require only a finite number of call strings even in the presence of recursion. Moreover, there is no loss of precision as all relevant call strings are constructed. We briefly describe value-based termination of call strings for forward analysis. Let df (σ, n) denote the data flow value for call string σ at the entry of node n. Let df (σ1 , Sp ) = df (σ2 , Sp ) = v. Since data flow values are propagated along the same set of paths from Sp to Ep , df (σ1 , Sp ) = df (σ2 , Sp ) ⇒ df (σ1 , Ep ) = df (σ2 , Ep ). Thus, we can propagate only one of them (say hσ1 , vi) through the body of p. Let it reach Ep as hσ1 , v ′ i. Then we can regenerate hσ2 , v ′ i at Ep by using df (σ1 , Ep ) if we remember that σ2 was represented by σ1 at Sp . Recursion creates cyclic call strings γαi where γ and α are non-overlapping call site sequences and α occurs i times. Since the lattice is finite and the flow functions are monotonic, some k ≥ 0 must exist such that df (γαk+m , Sp ) = df (γαk , Sp ) where m is the periodicity3 of the flow function for α. Hence γαk+m is represented by γαk . Since df (γαk+i·m , Sp ) = df (γαk , Sp ), i > 0, call string γαk+m is constructed for rep- resentation but call strings γαk+i·m , i > 1 are not constructed. Let df (γαk , Ep ) be v. Then we generate hγαk+m , vi in Out Ep which is propagated along the sequence of re- turn nodes thereby removing one occurrence of α. Thus the call string reaches Ep as γαk , once again to be regenerated as γαk+m . This continues until the values change, effectively computing df (γαk+i·m , Ep ), i > 1 without constructing the call strings. 3 Liveness-Based Pointer Analysis We consider the four basic pointer assignment statements: x = &y, x = y, x = ∗y, ∗x = y using which other pointer assignments can be rewritten. We also assume a use x statement to model other uses of pointers (such as in conditions). Discussion of address-taken local variables and allocation (new or malloc) is deferred to Section 5. Let V denote the set of variables (i.e. “named locations”). Some of these variables (those in P ⊂ V ) can hold pointers to members of V . Other members of V hold non- 3 x is a periodic point of f if f m (x) = x and f i (x) 6= x, 0 < i < m. If m = 1, x is a fixed point of f . See Fig. 9.12 on page 316 in [1] for a points-to analysis example where m = 2. 5

pointer values. These include variables of non-pointer type such as int. NULL is sim- ilarly best regarded as a member of V − P; finally a special value ‘?’ in V − P denotes an undefined location (again Section 5 discusses this further). Points-to information is a set of pairs (x, y) where x ∈ P is the pointer of the pair and y ∈ V is a pointee of x and is also referred to as the pointee of the pair. The pair (x, ?) being associated with program point n indicates that x may contain an invalid address along some potential execution path from Sp to n. The data flow variables Lin n and Lout n give liveness information for statement n while Ainn and Aout n give may-points-to information. Must-points-to information, Uinn and Uout n , is calculated from may-points-to. Note that liveness propagates back- wards (transfer functions map out to in) while points-to propagates forwards. The lattice of liveness information is L = hP(P), ⊇i (we only track the data flow of pointer variables) and lattice of may-points-to information is A = hP(P × V ), ⊇i. The overall data flow lattice is the product L × A with partial order hl1 , a1 i ⊑ hl2 , a2 i ⇔ (l1 ⊑ l2 ) ∧ (a1 ⊑ a2 ) ⇔ (l1 ⊇ l2 ) ∧ (a1 ⊇ a2 ) and having ⊤ element h∅, ∅i and ⊥ element hP, P × V i. We use standard algebraic operations on points-to relations: given relation R ⊆ P × V and X ⊆ P, define relation application R X = {v | u ∈ X ∧ (u, v) ∈ R} and relation restriction R|X = {(u, v) ∈ R | u ∈ X}. Data Flow Equations. Fig. 4 provides the data flow equations for liveness-based pointer analysis. They resemble the standard data flow equations of strong liveness anal- ysis and pointer analyses [1] except that liveness and may-points-to analyses depend on each other (hence the combined data flow is bi-directional in a CFG) and must-points-to information is computed from may-points-to information. Since we use the greatest fixpoint formulation, the initial value (⊤ of the corre- sponding lattices) is ∅ for both liveness and may-points-to analyses. For liveness BI is ∅ and defines Lout Ep ; for points-to analysis, BI is Linn × {?} and defines AinSp . This reflects that no pointer is live on exit or holds a valid address on entry to a procedure. Extractor Functions. The flow functions occurring in Equations (3) and (5) use ex- tractor functions Defn , Killn , Refn and Pointeen which extract the relevant pointer variables for statement n from the incoming pointer information Ainn . These extractor functions are inspired by similar functions in [3, 4]. Defn gives the set of pointer variables which a statement may modify and Pointeen gives the set of pointer values which may be assigned. Thus the new may-points-to pairs generated for statement n are Defn × Pointeen (Equation 5). Refn computes the variables that become live in statement n. Condition Defn ∩ Lout n ensures that Refn computes strong liveness rather than simple liveness. As an exception to the general rule, x is considered live in statement ∗x = y regardless of whether the pointees of x are live otherwise, the pointees of x would not be discovered. For example, given {x=&a; y=3; *x=y; return;}, (x, a) cannot be discovered unless x is marked live. Hence liveness of x cannot depend on whether the pointees of x are live. By con- trast, statement y = ∗x uses the liveness of y to determine the liveness of x. Killn identifies pointer variables that are definitely modified by statement n. This in- formation is used to kill both liveness and points-to information. For statement ∗x = y, 6

Given relation R ⊆ P × V (either Ainn or Aout n ) we first define an auxiliary extractor function [ V R{x} = ∅ ∨ R{x} = {?} Must(R) = {x} × {y} R{x} = {y} ∧ y 6= ? (1) ∅ otherwise x∈P Extractor functions for statement n (Defn , Killn , Refn ⊆ P; Pointeen ⊆ V ) Notation: we assume that x, y ∈ P and a ∈ V . A abbreviates Ainn . Refn Stmt. Defn Killn Pointeen if Defn ∩ Lout n 6= ∅ Otherwise use x ∅ ∅ {x} {x} ∅ x = &a {x} {x} ∅ ∅ {a} x=y {x} {x} {y} ∅ A{y} x = ∗y {x} {x} {y} ∪ (A{y} ∩ P) ∅ A(A{y} ∩ P) ∗x = y A{x} ∩ P Must(A){x} ∩ P {x, y} {x} A{y} other ∅ ∅ ∅ ∅ ∅ Data Flow Values: Linn , Lout n ⊆ P Ainn , Aout n ⊆ P × V [∅ n is Ep Lout n = Lins otherwise (2) s∈succ(n) Linn = (Lout n − Killn ) ∪ Refn (3) Linn ×{?} n is Sp Ainn = [ (4) Aout p otherwise p∈pred(n) Linn Aout n = ((Ainn − (Killn ×V )) ∪ (Defn ×Pointeen )) |Lout n (5) Fig. 4. Intraprocedural formulation of liveness-based pointer analysis. Killn depends on Ainn filtered using the function Must. When no points-to information for x is available, the statement ∗x = y marks all pointers as killed; this theoretically reflects the need for Killn to be anti-monotonic and practically that unreachable or C- undefined code is analysed liberally. When the points-to information for x is non-empty, Must performs a weak update or a strong update according to the number of pointees4 : when x has multiple pointees we employ weak update as we cannot be certain which one will be modified because x may point to different locations along different exe- cution paths reaching n. By contrast, when x has a single pointee other than ‘?’, it indicates that x points to the same location along all execution paths reaching n and a strong update can be performed. Having BI be Linn × {?} completes this: if there is a definition-free path from Sp to statement n, the pair (x, ?) will reach n and so a pair (x, z) reaching n cannot be incorrectly treated as a must-points-to pair. 4 Or whether x is a summary node (see Section 5). Here we ignore summary nodes. 7

q = &r 1 q = &r 1 {q}L , {(q, r)}A {q, r}L , {(q, r)}A {q}L , {(q, r)}A {q, r}L , {(q, r), (r, s)}A p=q 2 p=q 2 {p, q}L , {(p, r), (q, r)}A {p, q, r}L , {(p, r), (q, r), (r, s)}A {p, q}L , {(p, r), (q, r)}A {p, q, r}L , {(p, r), (q, r), (r, s)}A p = ∗p 3 p = ∗p 3 {q}L , {(q, r)}A {q}L , {(q, r)}A {p, q}L , {(q, r)}A {p, q}L , {(p, s), (q, r)}A s=q 5 s=q 5 {p, q}L , {(q, r)}A {p, q}L , {(p, s), (q, r)}A {q}L , {(q, r)}A {q}L , {(q, r)}A print p 4 print p 4 {q}L , {(q, r)}A {q}L , {(q, r)}A {q}L , {(q, r)}A {q}L , {(q, r)}A r = &s 6 r = &s 6 {q}L , {(q, r)}A {q, r}L , {(q, r), (r, s)}A {}L , {}A {}L , {}A p = ∗p 7 p = ∗p 7 First round of liveness and points-to Second round of liveness and points-to Fig. 5. Intraprocedural liveness-based points-to analysis of the program in Fig. 3. Shaded boxes show the liveness and points-to information suffixed by L and A respectively. The above discussion of Killn and Must justifies why must-points-to analysis need not be performed as an interdependent fixed-point computation [4, 1]. Given pointer x, a single points-to pair (x, y) with y 6= ? in Ain n or Aout n , guarantees that x points to y. Conversely multiple may-points-to pairs associated with x means that its must-points-to information is empty.5 Hence must-points-to information can be extracted from may- points-to information by Uinn = Must(Ainn ) and Uout n = Must(Aout n ). Note that generally Uinn ⊆ Ain n and Uout n ⊆ Aout n ; the only exception would be for nodes that are not reached by the analysis because no pointer has been found to be live. For such nodes Uinn , Uout n are P × V whereas Ain n , Aout n are ∅; this matches previous frameworks and corresponds to Must being anti-monotonic (see above). Motivating Example Revisited. Fig. 5 gives the result of liveness-based pointer anal- ysis for our motivating example of Fig. 3. After the first round of liveness analysis followed by points-to analysis, we discover pair (p, r) in Ain 3 . Thus r becomes live requiring a second round of liveness analysis. This then enables discovering the points- to pair (r, s) in node 6. A comparison with traditional may-points-to analysis (Fig. 3) shows that our analysis eliminates many redundant points-to pairs. 5 This is more general than a similar concept for flow-sensitive kill in [11]. See Section 6. 8

Correctness. The following two claims are sufficient to establish soundness: (a) the flow functions in our formulation are monotonic (Theorem 1), and (b) for every use of a pointer, the points-to information defined by our formulation contains all addresses that it can hold at run time at a given program point (Theorem 2). Point (a) guarantees MFP computation at the intraprocedural level; at the interprocedural level, the full call- strings method ensures IMFP computation; point (b) guarantees that MFP (or IMFP) contains all usable pointer information. Theorem 1. The function Must is anti-monotonic hence the transfer functions Linn , Lout n , Ainn and Aout n in Fig. 4 are monotonic. Theorem 2. If x ∈ P holds the address of z ∈ (V − {?}) along some execution path reaching node n, then x ∈ Refn ⇒ (x, z) ∈ Ainn . 4 Interprocedural Liveness-Based Pointer Analysis When our intraprocedural liveness-based points-to analysis is lifted to the interprocedu- ral level using the call-strings method, Linn , Lout n and Ainn , Aout n become functions of contexts written as sets of pairs hσ, li, l ∈ L and hσ, ai, a ∈ A where σ is a call string reaching node n. Finally, the overall values of Ainn , Aout n are computed by merging (⊓) the values along all call strings. Matching Contexts for Liveness and Points-to Analysis. Since points-to information should be restricted to live ranges, it is propagated along the call strings constructed dur- ing liveness analysis. In the presence of recursion, we may need additional call strings for which liveness information may not yet be available. Such cases can be resolved by using the existing call strings as explained below. Let σa denote an acyclic call string and let σc = γαi be a cyclic call string (see Section 2). Then for liveness analysis: – The partitioning information for every σa is available because either hσa , xi has reached node n in procedure p or σa has been represented by some other call string. – Let df (γαi , n) differ for 0 ≤ i ≤ k but let df (γαk , n) = df (γαk+j , n), j > 0 (the periodicity m for liveness analysis is 1). Then the partitioning information is avail- able for only γαk and γαk+1 because γαk+j , j > 1 are not constructed. Consider a call string σ ′ reaching node n during points-to analysis. If σ ′ is an acyclic call string then its partitioning information and hence its liveness information is avail- able. If σ ′ is a cyclic call string γαi , its liveness information may not be available if it has not been constructed for liveness. In such a situation, it is sufficient to locate the longest γαl , l < i among the call strings that have been created and use its liveness information. This effect is seen below in our motivating example. Motivating Example Revisited. For brevity, let In and On denote the entry and exit of node n. In the first round of liveness (Fig. 6), z becomes live at I6 as hλ, ziL , reaches O13 , I13 , O12 , I12 , O11 as hc1 , ziL , becomes hc1 c2 , ziL at I11 , reaches O13 and 9

hλ, ziL hλ, (z, ?)iA hc1 c2 /c1 c2 c2 , (w, x), (z, x)iA hc1 /c1 c2 , wziL hc1 , (w, x), (z, ?)iA 1 Sm hλ, ziL hλ, (z, ?)iA 8 Sp 2 x = &y hc1 , wziL hc1 , wiL hc1 /c1 c2 , (w, x)iA hλ, ziL hλ, (z, ?)iA 9 z=w 3 w = &x hc1 , wziL hc1 /c1 c2 , (w, x), (z, x)iA hλ, wziL hλ, (w, x), (z, ?)iA 10 c2 4 c1 hc1 c2 , wziL hc1 c2 /c1 c2 c2 , (w, x), (z, x)iA hc1 , wziL hc1 , (w, x), (z, ?)iA hc1 c2 , ziL hc1 c2 /c1 c2 c2 , (z, x)iA hc1 , ziL hc1 , (z, ?)iA 11 r2 5 r1 hc1 , ziL hc1 /c1 c2 , (z, x)iA hλ, ziL hλ, (z, ?)iA 12 z = ∗z 6 print z hc1 , ziL hc1 /c1 c2 , ∅iA hλ, ∅iL hλ, ∅iA 13 Ep 7 Em hc1 , (z, ?)iA hλ, ∅iL hλ, ∅iA hc1 /c1 c2 , ziL hc1 c2 /c1 c2 c2 , (z, x)iA Fig. 6. Liveness and points-to information (subscripted with L and A) after the first round of interprocedural analysis. For brevity, set of live variables are represented as strings and ‘{’ and ‘}’ are omitted. Multiple call strings with the same data flow value are separated by a ‘/’. gets represented by hc1 , ziL . Hence hc1 c2 , ziL is not propagated within the body of p. hc1 c2 , ziL is regenerated at I8 , becomes hc1 , ziL at I10 , becomes hc1 , wiL at I9 . At O8 , it combines with hc1 , ziL propagated from I13 and becomes hc1 , w ziL . Thus c1 c2 is regenerated as hc1 c2 , w ziL at I8 . hc1 , w ziL reaches O4 and becomes hλ, w ziL at I4 . In the first round of points-to analysis (Fig. 6), since z is live at I1 , BI = hλ, (z, ?)iA . hλ, (w, x)iA is generated at O3 . Thus hc1 , (w, x), (z, ?)iA reaches I8 . This becomes hc1 , (w, x), (z, x)iA at O9 and reaches as hc1 c2 , (w, x), (z, x)iA at I8 . Since z is not live at I9 , hc1 c2 , (w, x)iA is propagated to I9 . This causes hc1 c2 c2 , (w, x), (z, x)iA to be generated at O10 which reaches I9 and is represented by hc1 c2 , (w, x), (z, x)iA . This is then regenerated as hc1 c2 c2 , (z, x)iA at O13 because only z is live at O13 . Note that we do not have the liveness information along c1 c2 c2 but we know (from above) that it is identical to that along c1 c2 . We get hc1 c2 , (z, x)iA and hc1 , (z, x)iA at O11 . Since we have no points-to information for x, we get hc1 c2 , ∅iA and hc1 , ∅iA at O12 . We leave it for the reader to verify that, in the second round (Fig. 7), x becomes live at I12 due to z = ∗z, reaches O2 and causes hλ, (x, y)iA to be generated. As a consequence, we get (z, y) at I12 . Note that (z, x) cannot reach I6 along any interpro- cedurally valid path. The invocation graph method [3] which is generally considered the most precise flow- and context-sensitive method, does compute (z, x) at I6 . This shows that it is only partially context-sensitive. L-CFPA is more precise than [3] not only because of liveness but also because it is fully context-sensitive. 10

hc1 /c1 c2 /c1 c2 c2 , xiL hc1 /c1 c2 , (x, y)iA 1 Sm 8 Sp 2 x = &y hc1 , (x, y)iA hc1 /c1 c2 , xiL hλ, xiL hλ, (x, y)iA 9 z=w 3 w = &x hc1 /c1 c2 , xiL hc1 , (x, y)iA hλ, xiL hλ, (x, y)iA 10 c2 4 c1 hc1 c2 /c1 c2 c2 , xiL hc1 c2 , (x, y)iA hc1 , xiL hc1 , (x, y)iA hc1 c2 /c1 c2 c2 , xiL hc1 c2 , (x, y), (z, y)iA hc1 , (z, y)iA 11 r2 5 r1 hc1 /c1 c2 , xiL hc1 , (x, y), (z, y)iA hλ, (z, y)iA 12 z = ∗z 6 print z hc1 c2 , xiL hc1 , (x, y), (z, y)iA 13 Ep 7 Em hc1 c2 /c1 c2 c2 , xiL hc1 /c1 c2 , (x, y), (z, y)iA Fig. 7. Second round of liveness and points-to analysis to compute dereferencing liveness and the resulting points-to information. Only the additional information is shown. 5 Heaps, Escaping Locals and Records Each data location statically specified in a program is an abstract location and may cor- respond to multiple actual locations. It may be explicitly specified by taking the address of a variable or implicitly specified as the result of new or malloc. For interprocedural analysis, we categorise all abstract locations as shown in Fig. 8. Define interprocedural locations as those abstract locations which are accessible in multiple contexts reaching a given program point or whose data flow values depend (via a dataflow equation) on another interprocedural location. These are the locations for which interprocedural data flow analysis is required. Global variables and heap lo- cations are interprocedural locations. For pointer analysis, a local variable x becomes an interprocedural location if its address escapes the procedure containing it, or there is an assignment x = y or x = ∗z with y, z or one of z’s pointees being an interprocedural location. Interprocedural locations for liveness analysis are similarly identified. It is easy to handle different instances of a local variable which is not an interproce- dural location (even if its address is taken). To see how other local variables are handled, consider a local variable x which becomes interprocedural from assignment x = y or x = ∗z as in the previous paragraph. Since call strings store context-sensitive data flow values of y and z, they also distinguish between instances of x whose data flow val- ues may differ. Thus, call strings inherently support precise interprocedural analysis of global variables and locals (even interprocedural locals) whose addresses do not escape (the entry “No∗ ” for the latter category in Fig. 8 indicates that interprocedural analysis is either not required or is automatically supported by call-strings method without any special treatment). 11

Local Variable Heap allocation Global Address Address does at a given Issue Variable escapes not escape source line How many instances can exist? Single Arbitrarily many Arbitrarily many Arbitrarily many Can a given instance be accessed in multiple calling contexts? Yes Yes No Yes Number of instances accessible At most Arbitrarily many At most one Arbitrarily many at a given program point? one Is interprocedural data flow Yes Yes No∗ Yes analysis required? Is a summary node required? No Yes No Yes Fig. 8. Categorisation of data locations for interprocedural pointer analysis Since the number of accessible instances of heap locations and locals whose ad- dresses escape is not bounded,6 we need to create summary nodes for them. It is difficult to distinguish between instances which are accessible in different contexts. Hence cre- ating a summary node implies that the data flow values are stored context insensitively (but flow sensitively) by merging values of all instances accessible at a given program point. A consequence of this decision is that strong updates on these abstract locations are prohibited; this is easily engineered by Must returning ∅ for summary-node pointees which is consistent with the requirements of Uinn /Uout n computation. Recall that Equation 1 does not treat ‘?’ as a summary node. This depends on the language-defined semantics of indirect writes via uninitialised pointers. In C (because the subsequent program behaviour is undefined) or Java (because of ‘NullPointerEx- ception’) it is safe to regard Must as returning all possible values when only ‘?’ occurs. Alternatively, were the semantics to allow subsequent code to be executed in a defined manner, then ‘?’ needs to be treated as a summary node so that Must returns ∅ and in- direct writes kill nothing (in general this results in reduced optimisation possibilities). Our implementation treats an array variable as a single scalar variable with weak up- date (no distinction is made between different index values). Stack-allocated structures are handled field-sensitively by using the offsets of fields. Heap-allocated structures are also handled field sensitively where possible. Function pointers are handled as in [3]. 6 Related Work The reported benefits of flow and context sensitivity for pointer analysis have been mixed in literature [12–15] and many methods relax them for efficiency [5, 6, 11, 16]. It has also been observed that an increase in precision could increase efficiency [17, 11]. Both these aspects have been studied without the benefit of liveness, partially explain- ing marginal results. Some methods lazily compute pointer information on demand [18– 21]. By contrast, L-FCPA does not depend on a client analysis and proactively computes the entire usable pointer information. If there are many demands, repeated incremental computations could be rather inefficient [22]. Efficient encoding of information by us- ing BDDs [23] has been an orthogonal approach of achieving efficiency. Although the 6 Local variables whose addresses escape may belong to recursive procedures. 12

usable pointer information discovered by L-FCPA is small, recording it flow sensitively in a large program may benefit from BDDs. The imprecision caused by flow insensitivity can be partially mitigated by using SSA representation which enables a flow-insensitive method to compute flow-sensitive information for local scalar variables. For pointers, the essential properties of SSA can only be guaranteed for top-level pointers whose address is not taken. Some improve- ments are enabled by Factored SSA [24] or Hashed SSA [25]. In the presence of global pointer variables or multiple indirections, the advantages of SSA are limited unless in- terleaved rounds of SSA construction and pointer analysis are performed [26, 27]. A re- cent method introduces flow-sensitive kill in an otherwise flow-insensitive method [11]. Full context sensitivity can be relaxed in many ways: (a) using a context-insensitive approach, (b) using a context-sensitive approach for non-recursive portions of a pro- gram but merging data flow information in the recursive portions (e.g. [3, 27–29]), or (c) using limited depth of contexts in both recursive and non-recursive portions (e.g. the k-limited call-strings method [7] or [23]). Most context-sensitive approaches that we are aware of belong to category (b). Our fully context-sensitive approach generalises partially context-sensitive approaches such as object-sensitivity [30, 12, 17] as follows. For an object x and its method f, a (virtual) call x.f (e1 , . . . , en ) is viewed as the call (x.f in vtab)(&x, e1 , . . . , en ). Thus object identification reduces to capturing the flow of values which is inherently supported by full flow and context sensitivity. We highlight some key ideas that have not been covered above. A memoisation- based functional approach enumerates partial transfer functions [28] whereas an al- ternative functional approach constructs full transfer functions hierarchically in terms of pointer indirection levels [27]. The invocation-graph-based approach unfolds a call graph in terms of call chains [3]. Finally, a radically different approach begins with flow- and context-insensitive information which is refined systematically to restrict it to flow- and context-sensitive information [29]. These approaches merge points-to infor- mation in recursive contexts (category (b) above). Fig. 9.6 (page 305) in [1] contains an example for which a method belonging to category (b) or (c) above cannot compute precise result—the pointer assignments in the recursion unwinding part undo the effect of the pointer assignments in the part that builds up recursion and the overall function is an identity function. When all recursive calls receive the same (merged) information, the undo effect on the pointer information cannot be captured. Finally, many investigations tightly couple analysis specification and implementa- tion; by contrast our formulation maintains a clean separation between the two and does not depend on intricate procedural algorithms or ad-hoc implementation for efficiency. 7 Implementation and Empirical Measurements We implemented L-FCPA and FCPA in GCC 4.6.0 using the GCC’s Link Time Op- timisation (LTO) framework.7 We executed them on various programs from SPEC CPU2006 and CPU2000 Integer Benchmarks on a machine with 16 GB RAM with 8 64-bit Intel i7-960 CPUs running at 3.20GHz. We compared the performance of three 7 They can be downloaded from http://www.cse.iitb.ac.in/grc/index.php?page=lipta. 13

Time in milliseconds Unique points-to pairs Call Program kLoC L-FCPA Sites FCPA GPTA L-FCPA FCPA GPTA Liveness Points-to lbm 0.9 33 0.55 0.52 1.9 5.2 12 507 1911 mcf 1.6 29 1.04 0.62 9.5 3.4 41 367 2159 libquantum 2.6 258 2.0 1.8 5.6 4.8 49 119 2701 bzip2 3.7 233 4.5 4.8 28.1 30.2 60 210 8.8×104 parser 7.7 1123 1.2×103 145.6 4.3×105 422.12 531 4196 1.9×104 sjeng 10.5 678 858.2 99.0 3.2×104 38.1 267 818 1.1×104 hmmer 20.6 1292 90.0 62.9 2.9×105 246.3 232 5805 1.9×106 h264ref 36.0 1992 2.2×10 2.0×105 5 ? 4.3×103 1683 ? 1.6×107 Table 1. Time and unique points-to pairs measurements. For h264ref, FCPA ran out of memory. methods: L-FCPA, FCPA and GPTA (GCC’s points-to analysis). Both L-FCPA and FCPA are flow and context sensitive and use call strings with value-based termination. L-FCPA uses liveness whereas FCPA does not. GPTA is flow and context insensitive but acquires partial flow sensitivity through SSA. Since our main goal was to find out if liveness increases the precision of points-to information, both L-FCPA and FCPA are naive implementations that use linked lists and linear searches within them. Our measurements confirm this hypothesis beyond doubt, but we were surprised by the overall implementation performance because we had not designed for time/space efficiency or scalability. We were able to run naive L-FCPA on programs of around 30kLoC but not on the larger programs. Table 1 presents the computation time and number of points-to pairs whereas Ta- bles 2 and 3 present measurements of points-to information and context information respectively. To measure the sparseness of information, we created four buckets of the numbers of points-to pairs and call strings: 0, 1–4, 5–8 and 9 or more. We counted the number of basic blocks for each bucket of points-to information and the number of functions for each bucket of context information. Our data shows that: – The usable pointer information is (a) rather sparse (64% of basic blocks have 0 points-to pairs), and (b) rather small (four programs have at most 8 points-to pairs and in other programs, 9+ points-to pairs reach fewer than 4% basic blocks). In contrast, GPTA computes an order-of-magnitude-larger number of points-to pairs at each basic block (see the last column in Table 1). – The number of contexts required for computing the usable pointer information is (a) rather sparse (56% or more basic blocks have 0 call strings), and (b) rather small (six programs have at most 8 call strings; in other programs, 9+ call strings reach less than 3% basic blocks). Thus, contrary to the common apprehension, context in- formation need not be exponential in practice. Value-based termination reduces the number of call strings dramatically [10] and the use of liveness enhances this effect further by restricting the computation of data flow values to the usable information. 14

Total No. and percentage of basic blocks (BBs) for points-to (pt) pair counts Program no. of 0 pt pairs 1-4 pt pairs 5-8 pt pairs 9+ pt pairs BBs L-FCPA FCPA L-FCPA FCPA L-FCPA FCPA L-FCPA FCPA lbm 252 229 61 23 82 0 66 0 43 (90.9%) (24.2%) (9.1%) (32.5%) (26.2%) (17.1%) 356 160 116 2 1 309 mcf 472 0 0 (75.4%) (33.9%) (24.6%) (0.4%) (0.2%) (65.5%) 1520 793 119 796 3 46 7 libquantum 1642 0 (92.6%) (48.3%) (7.2%) (48.5%) (0.2%) (2.8%) (0.4%) 2624 1085 118 12 3 12 1 1637 bzip2 2746 (95.6%) (39.5%) (4.3%) (0.4%) (0.1%) (0.4%) (0.0%) (59.6%) 9+ pt pairs in L-FCPA: Tot 1, Min 12, Max 12, Mean 12.0, Median 12, Mode 12 sjeng 6000 4571 3239 1208 12 221 41 0 2708 (76.2%) (54.0%) (20.1%) (0.2%) (3.7%) (0.7%) (45.1%) 13483 8357 896 21 24 91 15 5949 hmmer 14418 (93.5%) (58.0%) (6.2%) (0.1%) (0.2%) (0.6%) (0.1%) (41.3%) 9+ pt pairs in L-FCPA: Tot 6, Min 10, Max 16, Mean 13.3, Median 13, Mode 10 4823 1821 1591 25 252 154 209 4875 parser 6875 (70.2%) (26.5%) (23.1%) (0.4%) (3.7%) (2.2%) (3.0%) (70.9%) 9+ pt pairs in L-FCPA: Tot 13, Min 9, Max 53, Mean 27.9, Median 18, Mode 9 13729 ? 4760 ? 2035 ? 791 ? h264ref 21315 (64.4%) (22.3%) (9.5%) (3.7%) 9+ pt pairs in L-FCPA: Tot 44, Min 9, Max 98, Mean 36.3, Median 31, Mode 9 Table 2. Liveness restricts the analysis to usable pointer information which is small and sparse. The significant increase in precision achieved by L-FCPA suggests that a pointer anal- ysis need not compute exponentially large information. We saw this sub-exponential trend in programs of up to around 30kLoC and anticipate it might hold for larger pro- grams too—because although reachable pointer information may increase significantly, usable information need not accumulate and may remain distributed in the program. A comparison with GPTA shows that using liveness reduces the execution time too—L-FCPA outperforms GPTA for most programs smaller than 30kLoC. That a flow- and context-sensitive analysis could be faster than flow- and context-insensitive analysis came as a surprise to us. In hindsight, this is possible because the information that we can gainfully use is much smaller than commonly thought. Note that a flow- and context-insensitive analysis cannot exploit the small size of usable pointer information because it is small only when considered flow and context sensitively. The hypothesis that our implementation suffers because of linear search in linked lists was confirmed by an accidental discovery: in order to eliminate duplicate pairs in GPTA, we used our linear list implementation of sets from L-FCPA which never adds duplicate entries. The resulting GPTA took more than an hour for the hmmer pro- gram instead of the original 246.3 milliseconds! Another potential source of inefficiency concerns the over-eager liveness computation to reduce the points-to pairs in L-CFPA: a new round of liveness is invoked when a new points-to pair for y is discovered for x = ∗y putting on hold the points-to analysis. This explains the unusually large time 15

Total No. and percentage of functions for call-string counts Program no. of 0 call strings 1-4 call strings 5-8 call strings 9+ call strings functions L-FCPA FCPA L-FCPA FCPA L-FCPA FCPA L-FCPA FCPA lbm 22 16 3 6 19 0 0 0 0 (72.7%) (13.6%) (27.3%) (86.4%) 16 3 9 22 mcf 25 0 0 0 0 (64.0%) (12.0%) (36.0%) (88.0%) 88 38 12 62 bzip2 100 0 0 0 0 (88.0%) (38.0%) (12.0%) (62.0%) libquantum 118 100 56 17 62 1 0 0 0 (84.7%) (47.5%) (14.4%) (52.5%) (0.8%) sjeng 151 96 37 43 45 12 15 0 54 (63.6%) (24.5%) (28.5%) (29.8%) (7.9%) (9.9%) (35.8%) 548 330 32 175 4 26 53 hmmer 584 0 (93.8%) (56.5%) (5.5%) (30.0%) (0.7%) (4.5%) (9.1%) 246 76 118 135 4 63 4 98 parser 372 (66.1%) (20.4%) (31.7%) (36.3%) (1.1%) (16.9%) (1.1%) (26.3%) 9+ L-FCPA call strings: Tot 4, Min 10, Max 52, Mean 32.5, Median 29, Mode 10 351 ? 240 ? 14 ? 19 ? h264ref 624 (56.2%) (38.5%) (2.2%) (3.0%) 9+ L-FCPA call strings: Tot 14, Min 9, Max 56, Mean 27.9, Median 24, Mode 9 Table 3. Context information for computing usable pointer information is small and sparse. spent in liveness analysis compared to points-to analysis for programs parser and sjeng. The number of rounds of analysis required for these programs was much higher than in other programs of comparable size. Finally, GCC’s LTO framework has only two op- tions: either to load no CFG or to load all CFGs at the same time. Since the size of the entire program could be large, this affects the locality and hence the cache behaviour. 8 Conclusions and Future Work We have described a data flow analysis which jointly calculates points-to and live- ness information. It is fully flow- and context-sensitive and uses recent refinements of the call-strings approach. One novel aspect of our approach is that it is effectively bi-directional (such analysis seem relatively rarely exploited). Initial results from our naive prototype implementation were impressive: unsurpris- ingly our analysis produced much more precise results, but by an order of magnitude (in terms of the size of the calculated points-to information). The reduction of this size al- lowed our naive implementation also to run faster than GCC’s points-to analysis at least for programs up to 30kLoC. This is significant because GCC’s analysis compromises both on flow and context sensitivity. This confirms our belief that the usable pointer information is so small and sparse that we can achieve both precision and efficiency without sacrificing one for the other. Although the benefit of precision in efficiency has been observed before [17, 11], we are not aware of any study that shows the sparseness and small size of points-to information to this extent. 16

We would like to take our work further by exploring the following: – Improving our implementation in ways such as: using efficient data structures (vec- tors or hash tables, or perhaps BDDs); improving GCC’s LTO framework to allow on-demand loading of individual CFGs instead of loading the complete supergraph; and experimenting with less-eager strategies of invoking liveness analysis. – Exploring the reasons for the 30kLoC speed threshold; perhaps there are ways in practice to partition most bigger programs (around loosely-coupled boundaries) without significant loss of precision. – We note that data flow information often only slightly changes when revisiting a node compared to the information produced by the earlier visits. Hence, we plan to explore incremental formulations of L-FCPA. – GCC passes hold alias information in a per-variable data structure thereby using the same information for every occurrence of the variable. We would like to change this to use point-specific information computed by L-FCPA and measure how client analyses/optimisations benefit from increased precision. Acknowledgements. Prashant Singh Rawat was supported by GCC Resource Cen- ter funding as part of the Government of India’s National Resource Center for Free and Open Source Software (NRCFOSS). Empirical measurements were carried out by Prachee Yogi and Aboli Aradhye. Prachee also implemented intraprocedural analysis in Prolog. Ashwin Paranjape was involved in initial explorations. We are grateful to the anonymous referee who requested more detail on our treatment of allocation and summary nodes (Section 5); this helped our presentation. References 1. Khedker, U.P., Sanyal, A., Karkare, B.: Data Flow Analysis: Theory and Practice. CRC Press, Inc. (2009) 2. Kildall, G.A.: A unified approach to global program optimization. In: Proc. of POPL’73. (1973) 194–206 3. Emami, M., Ghiya, R., Hendren, L.J.: Context-sensitive interprocedural points-to analysis in the presence of function pointers. In: Proc. of PLDI’94. (1994) 242–256 4. Kanade, A., Khedker, U.P., Sanyal, A.: Heterogeneous fixed points with application to points-to analysis. In: Proc. of APLAS’05. (2005) 298–314 5. Andersen, L.O.: Program Analysis and Specialization for the C Programming Language. PhD thesis, DIKU, University of Copenhagen (1994) 6. Steensgaard, B.: Points-to analysis in almost linear time. In: Proc. of POPL’96. (1996) 32–41 7. Sharir, M., Pnueli, A.: Two approaches to interprocedural data flow analysis. In Muchnick, S.S., Jones, N.D., eds.: Program Flow Analysis : Theory and Applications. Prentice-Hall Inc. (1981) 8. Reps, T., Horwitz, S., Sagiv, M.: Precise interprocedural dataflow analysis via graph reach- ability. In: Proc. of POPL’95. (1995) 49–61 9. Knoop, J., Steffen, B.: The interprocedural coincidence theorem. In: Proc. of CC’92. (1992) 125–140 10. Khedker, U.P., Karkare, B.: Efficiency, precision, simplicity, and generality in interproce- dural data flow analysis: Resurrecting the classical call strings method. In: Proc. of CC’08. (2008) 213–228 17

11. Lhoták, O., Chung, K.A.: Points-to analysis with efficient strong updates. In: Proc. of POPL’11. (2011) 3–16 12. Lhoták, O., Hendren, L.J.: Context-sensitive points-to analysis: Is it worth it? In: Proc. of CC’06. (2006) 47–64 13. Ruf, E.: Context-insensitive alias analysis reconsidered. In: Proc. of PLDI’95. (1995) 13–22 14. Shapiro, M., Horwitz, S.: The effects of the precision of pointer analysis. In: Proc. of SAS’97. (1997) 16–34 15. Hind, M., Pioli, A.: Assessing the effects of flow-sensitivity on pointer alias analyses. In: Proc. of SAS’98. (1998) 57–81 16. Hardekopf, B.C., Lin, C.: The ant and the grasshopper: Fast and accurate pointer analysis for millions of lines of code. In: Proc. of PLDI’07. (2007) 290–299 17. Smaragdakis, Y., Bravenboer, M., Lhoták, O.: Pick your contexts well: Understanding object-sensitivity. In: Proc. of POPL’11. (2011) 17–30 18. Guyer, S.Z., Lin, C.: Client-driven pointer analysis. In: Proc. of SAS’03. (2003) 214–236 19. Heintze, N., Tardieu, O.: Demand-driven pointer analysis. In: Proc. of PLDI’01. (2001) 24–34 20. Sridharan, M., Gopan, D., Shan, L., Bodı́k, R.: Demand-driven points-to analysis for Java. In: Proc. of OOPSLA’05. (2005) 59–76 21. Zheng, X., Rugina, R.: Demand-driven alias analysis for C. In: Proc. of POPL’08. (2008) 197–208 22. Rosen, B.K.: Linear cost is sometimes quadratic. Proc. of POPL’81 (1981) 117–124 23. Whaley, J., Lam, M.S.: Cloning-based context-sensitive pointer alias analysis using binary decision diagrams. In: Proc. of PLDI’04. (2004) 131–144 24. Choi, J.D., Cytron, R., Ferrante, J.: On the efficient engineering of ambitious program anal- ysis. IEEE Trans. Softw. Eng. 20 (1994) 105–114 25. Chow, F.C., Chan, S., Liu, S.M., Lo, R., Streich, M.: Effective representation of aliases and indirect memory operations in SSA form. In: Proc. of CC’96. (1996) 253–267 26. Hasti, R., Horwitz, S.: Using static single assignment form to improve flow-insensitive pointer analysis. In: Proc. of PLDI’98. (1998) 97–105 27. Yu, H., Xue, J., Huo, W., Feng, X., Zhang, Z.: Level by level: making flow- and context- sensitive pointer analysis scalable for millions of lines of code. In: Proc. of CGO’10. (2010) 218–229 28. Wilson, R.P., Lam, M.S.: Efficient context-sensitive pointer analysis for C programs. In: Proc. of POPL’95. (1995) 1–12 29. Kahlon, V.: Bootstrapping: a technique for scalable flow and context-sensitive pointer alias analysis. In: Proc. of PLDI’08. (2008) 249–259 30. Milanova, A., Rountev, A., Ryder, B.G.: Parameterized object sensitivity for points-to anal- ysis for Java. ACM Trans. Softw. Eng. Methodol. 14 (2005) 1–41 18

You can also read