Generalized Points-to Graphs: A Precise and Scalable Abstraction for Points-to Analysis Generalized Points-to Graphs: A Precise and Scalable Abstraction for Points-to Analysis

We focus on exhaustive as against demand-driven [7, 13, 36, 37] points-to analysis. A demand-driven points-to analysis computes points-to information that is relevant to a query raised by a client analysis; for a different query, the points-to analysis needs to be repeated. An exhaustive analysis, however, computes all points-to information that can be queried later by a client analysis; multiple queries do not require points-to analysis to be repeated. For precision of points-to information, we are interested in full flow- and context-sensitive points-to analysis. A flow-sensitive analysis respects the control flow and computes separate dataflow information at each program point. This matters because a pointer could have different pointees at different program points because of redefinitions. Hence, a flow-sensitive analysis provides more precise results than a flow-insensitive analysis but can become inefficient at the interprocedural level. A context-sensitive analysis distinguishes between different calling contexts of procedures and restricts the analysis to interprocedurally valid control flow paths (i.e., control flow paths from program entry to program exit in which every return from a procedure is matched with a call to the procedure such that all call-return matchings are properly nested). A fully context-sensitive analysis does not lose precision even in the presence of recursion. Both flow- and context-sensitivity enhance precision, and we aim to achieve this without compromising efficiency.

A top-down approach to interprocedural context-sensitive analysis propagates information from callers to callees [47] effectively traversing the call graph top-down. In the process, it analyzes a procedure each time a new dataflow value reaches it from some call. Several popular approaches fall in this category: the call-strings method [34], its value-based variants [20, 29], and the tabulation-based functional method [30, 34]. By contrast, bottom-up approaches [5, 9, 12, 16, 26, 32, 39, 42, 43, 44, 45, 46, 47] avoid analyzing a procedure multiple times by constructing its procedure summary, which is used to incorporate the effect of calls to the procedure. Effectively, this approach traverses the call graph bottom-up.¹ A flow- and context-sensitive interprocedural analysis using procedure summaries is performed in two phases: the first phase constructs the procedure summaries, and the second phase uses them to represent the effect of the calls at the call sites.

For points-to analysis, an additional dimension of context sensitivity arises because heap locations are typically abstracted using allocation sites—all locations allocated by the same statement are treated alike. These allocation sites could be created context insensitively or could be cloned based on the contexts. We summarize various methods of points-to analysis using the metric described in Figure 20 and use it to position our work in Section 11.

Most approaches to precise points-to analysis begin with a scalable but imprecise method and then seek to increase its precision. We take the opposite approach in that we begin with a precise method and increase its scalability. We create naive, possibly non-scalable, procedure summaries and then use novel optimizations to compact them while retaining their soundness and precision. More specifically, we advocate a new form of bottom-up procedure summaries, called the generalized points-to graphs (GPGs) for flow- and context-sensitive points-to analysis. GPGs represent memory transformers (summarizing the effect of a procedure) and contain generalized points-to updates (GPUs) representing individual memory updates along with the control flow between them. GPGs are compact—their compactness is achieved by a careful choice of a suitable representation and a series of optimizations as described next:

1. Our representation of memory updates—the GPU, denoted $\gamma$—leavesaccesses of unknown pointees implicit without losing precision.
   
2. GPGs undergo aggressive optimizations that are applied repeatedly to improve the compactness of GPGs incrementally. They are governed by the following possibilities of data dependence of a GPU $\text{$\gamma $} _2$ on another GPU $\text{$\gamma $} _1$ (illustrated in Section 2.2).
   
   • Case A:The dependence of $\text{$\gamma $} _2$ on $\text{$\gamma $} _1$ can be determined. Then, there are two possibilities:
     
     1. GPU $\text{$\gamma $} _2$ follows $\text{$\gamma $} _1$ on some control flow path and has the following kind of dependence on $\text{$\gamma $} _1$: (a) a read-after-write (RaW) dependence, (b) a write-after-read (WaR) dependence, or (c) a write-after-write (WaW) dependence. A read-after-read (RaR) dependence is irrelevant.
        
     2. GPU $\text{$\gamma $} _2$ does not have a dependence on $\text{$\gamma $} _1$.
        
   • Case B: More information is needed to determine whether or not $\text{$\gamma $} _2$ has a dependence on $\text{$\gamma $} _1$. Then, $\text{$\gamma $} _2$ has a potential dependence on $\text{$\gamma $} _1$. We use source-language type information ubiquitously to rule out potential dependence following C-style rules on indirect accesses via type-casted pointers. This resolves some instances of case B into case A.ii.
     
   These cases are exploited by three classes of optimizations as described next:
   
   • Elimination of data dependence: These optimizations attempt to eliminate data dependences between GPUs so that the control flow can be minimized. The strength reduction optimization exploits the RaW dependence (case A.i.a) of GPU $\text{$\gamma $} _2$ on GPU $\text{$\gamma $} _1$. It simplifies GPU $\text{$\gamma $} _2$ by reducing the pointer indirection levels in it by using the pointer information from $\text{$\gamma $} _1$ to eliminate the data dependence between them. The dead GPU elimination optimization exploits the WaW dependence (case A.i.b) between GPU $\text{$\gamma $} _1$ and $\text{$\gamma $} _2$. If the locations written by $\text{$\gamma $} _1$ are rewritten by $\text{$\gamma $} _2$ along every path reaching the end of the procedure, $\text{$\gamma $} _1$ does not have any effect on the callers. Deleting it eliminates the WaW dependence between $\text{$\gamma $} _1$ and $\text{$\gamma $} _2$.
     
   • Control flow minimization: These optimizations exploit the WaR dependence (case A.i.c) and the absence of data dependence (case A.ii). They discard control flow selectively by converting some sequentially ordered GPUs into parallel GPUs when there is WaR dependence or no dependence between them—since all reads precede any write in parallel assignments, they preserve WaR dependences inherently. When there are RaW or WaW dependences between GPUs, we preserve control flow between them.
     
   • Call inlining: This optimization handles case B by progressively providing more information. It inlines the summaries of the callees of a procedure enhancing the opportunities of strength reduction and control flow optimization and enabling context-sensitive analyses. Recursive calls are handled by refining the GPGs through a fixed-point computation. Calls through function pointers are handled through delayed inlining.
     Our measurements suggest that the real killer of scalability in program analysis is not the amount of data but the amount of control flow that the data propagation may be subjected to in search of precision. Our optimizations are effective because they eliminate data dependence wherever possible and discard irrelevant control flow. This aids the scalability of points-to analysis without violating soundness or causing imprecision.
     
3. Interleaving call inlining and strength reduction of GPGs facilitates a novel optimization that computes flow- and context-sensitive points-to information in the first phase of a bottom-up approach. This obviates the need for the usual second phase of a bottom-up analysis.
   

These optimizations are based on the following novel operations and analyses:

• We define operations of GPU composition and GPU reduction to simplify a GPU using the information from RaW dependences, thereby eliminating the dependences.
  
• We perform reaching GPUs analysis (to identify the GPUs reaching a given statement) and coalescing analysis (to remove control flow edges while preserving soundness and precision).
  

At a practical level, our main contribution is a method of flow-sensitive, field-sensitive, and context-sensitive exhaustive points-to analysis of C programs that scales to large real-life programs.

The core ideas of GPGs have been presented before [11]. This article provides a complete treatment and enhances the core ideas significantly. We describe our formulations for a C-like language.

Section 2 describes the limitations of past approaches. Section 3 introduces the concept of GPUs that form the basis of GPGs and provides an overview of GPG construction through a motivating example. Section 4 describes the strength reduction optimization performed on GPGs. Section 5 explains dead GPU elimination. Section 6 describes control flow minimization optimizations performed on GPGs. Section 7 explains the interprocedural use of GPGs by defining call inlining and shows how recursion is handled. Section 8 shows how GPGs are used for performing points-to analysis. Section 9 proves soundness and precision of our method by showing its equivalence with a top-down flow- and context-sensitive classical points-to analysis. Section 10 presents empirical evaluation on SPEC benchmarks, and Section 11 describes related work. Section 12 concludes the article.

Some details (handling fields of structures and union, heap memory, function pointers, etc.) are available in an appendix available electronically.² We have included cross references to the material in the appendix where relevant.

In this section, we describe the nature of memory, memory updates, and memory transformers.

In the absence of indirect assignments involving pointers, data dependence between memory updates within a procedure can be inferred by using variable names without requiring any information from the callers. In such a situation, procedure summaries for some analyses, including various bit-vector dataflow analyses (e.g., live variables analysis), can be precisely represented by constant gen and kill sets [1, 22] or graph paths discovered using reachability [30].

Procedure summaries for points-to analysis, however, cannot be represented in terms of constant gen and kill sets because the association between pointer variables and their pointee locations could change in the procedure and may depend on the aliases between pointer variables established in the callers of the procedure. Often, and particularly for points-to analysis, we have a situation where a procedure summary must either lose information or retain internal details that can only be resolved when its caller is known.

The preceding example illustrates the following challenges in constructing flow-sensitive memory transformers: (a) representing indirectly accessed unknown pointees, (b) identifying blocking assignments and postponing some optimizations, and (c) recording control flow between memory updates so that potential data dependence between them is neither violated nor overapproximated.

Thus, a flow-sensitive memory transformer for points-to analysis requires a compact representation for memory updates that captures the minimal control flow between them succinctly.

Fig. 1. STF-style memorytransformers and associated transformations. Unknown pointees are denoted by placeholders $\phi _i$. Thick edges in a memory transformer represent the points-to edges generated by it, whereas other edges are carried forward from the input memory.

A common solution for modeling indirect accesses of unknown pointees in a memory transformer is to use placeholders (also known as external variables [26, 39, 42] and extended parameters [43]). They are pattern-matched against the input memory to compute the output memory. Here we describe two broad approaches that use placeholders.

The first approach, which we call a multiple transfer functions (MTFs) approach, proposed a precise representation of a procedure summary for points-to analysis as a collection of (conditional) partial transfer functions (PTFs) [5, 16, 43, 46]. Each PTF corresponds to a combination of aliases that might occur in the callers of a procedure. Our work is inspired by the second approach, which we call a single transfer function (STF) approach [4, 6, 23, 26, 27, 39, 42]. This approach does not customize procedure summaries for combinations of aliases. However, the existing STF approach fails to be precise. We illustrate this approach and its limitations to motivate our key ideas using Figure 1. It shows a procedure and two memory transformers ($\text{$\Delta $}^{\prime }$ and $\text{$\Delta $}^{\prime \prime }$) for it and the associated input and output memories. The effect of $\text{$\Delta $}^{\prime }$ is explained in Example 2 and that of $\text{$\Delta $}^{\prime \prime }$ in Example 3.

The use of control flow ordering between the points-to edges that are generated by a memory transformer can improve its precision as shown by the following example.

Observe that although $\text{$\Delta $}^{\prime \prime }$ is more precise than $\text{$\Delta $}^{\prime }$, it uses a larger number of placeholders and also requires control flow information. This affects the scalability of points-to analysis.

A fundamental problem with placeholders is that they use a low-level representation of memory expressed in terms of classical points-to edges. Hence, a placeholder-based approach is forced to explicate unknown pointees by naming them, resulting in either a large number of placeholders (in the STF approach) or multiple PTFs (in the MTF approach). The need of control flow ordering further increases the number of placeholders in the former approach.

Fig. 2. A motivating example. Procedures are represented by their control flow graphs.

We propose a GPG as a representation for a memory transformer of a procedure; special cases of GPGs also represent memory as a points-to relation. A GPG is characterized by the following key ideas that overcome the two limitations described in Section 2.3:

• A GPG leaves the placeholders implicit by using the counts of indirection levels. Simple arithmetic on the counts allows us to combine the effects of multiple memory updates.
  
• A GPG uses a flow relation to order memory updates. Interestingly, it can be compressed dramatically without losing precision and can be optimized into a compact acyclic flow relation in most cases, even if the procedure it represents has loops or recursive calls.
  

Section 3 illustrates them using a motivating example and gives a big-picture view.

We model the effect of a pointer assignment on an abstract memory by defining the concept of GPU in Definition 1, which gives the abstract semantics of a GPU. The concrete semantics of a GPU $x \mathop {\longrightarrow }\limits _{s}^{i|j} y$ can be viewed as the following C-style pointer assignment with $i-1$ dereferences of $x$ (or $i$ dereferences of $\&x$) and $j$ dereferences of $\&y$.

Definition 1. Generalized points-to update.

This conceptual understanding of a GPU is central to the development of this work. However, most compiler intermediate languages are at a lower level of abstraction and instead represent this GPU using (placeholder) temporaries $l_k \, (0\le k \lt i)$ and $r_k \, (0\le k \le j)$ as a sequence of C-style assignments (illustrated inFigure 3):⁴

Statement labels, $s$, in GPUs are unique across procedures to distinguish between the statements of different procedures after call inlining. They facilitate distinguishing between strong and weak updates by identifying may-defined pointers (Section 3.1.1). Further, since GPUs are simplified in the calling contexts, statement labels allow back-annotation of points-to information within the procedure to which they belong. For simplicity, we omit the statement labels from GPUs when they are not required.

A GPU $\text{$\gamma $}:x \mathop {\longrightarrow }\limits _{s}^{i|j} y$ generalizes a points-to edge⁵ from $x$ to $y$ with the following properties:

• The direction indicates that the source $x$ with indlev $i$ identifies the locations being defined and the target $y$ with indlev $j$ identifies the locations whose addresses are read. We often refer to $(x,i)$ as the source of $\gamma$ and $(y,j)$ as its target.
  
• The GPU $\gamma$ abstracts away $i-1+j$ placeholders.
  
• The GPU $\gamma$ represents may information because different locations may be reached from $x$ and $y$ along different control flow paths reaching statement $s$ in the procedure.
  

We refer to a GPU with $i=1$ and $j=0$ as a classical points-to edge, as it encodes the same information as edges in classical points-to graphs.

Fig. 3. GPUs and their memory graphs for basic pointer assignments in C (left) and for a general GPU (right). Solid circles represent memory locations, some of which are unknown. A double circle indicates the location whose address is being assigned, and a thick arrow shows the generated edge representing the effect of the assignment. In abstract memory, the circles may represent multiple locations.

Figure 3 presents the GPUs for basic pointer assignments in C and for the general GPU $x \mathop {\longrightarrow }\limits _{s}^{i|j} y$. (To deal with C structs and unions, GPUs are extended to encode lists of field names—for details see Figure B.1 in Appendix B).

GPUs are useful rubrics of our abstractions because they can be composed to construct new simplified GPUs (i.e., GPUs with smaller indirection levels) whenever possible, thereby converting them progressively to classical points-to edges. The composition between GPUs eliminates RaW dependence between them and thereby the need for control flow ordering between them.

Definition 2. Generalized points-to blocks and generalized points-to graphs.

A GPU can be seen as a primitive memory transformer that is used as a building block for the GPG as a memory transformer for a procedure (Definition 2). The optimized GPG for a procedure differs from its control flow graph (CFG) in the following way:

• The CFG could have procedure calls, but an optimized GPG does not. We observe that an optimized GPG is acyclic in almost all cases, even if a procedure has loops or recursive calls.
  
• The GPBs that form the nodes in a GPG are analogous to the basic blocks of a CFG except the basic blocks are sequences of statements but GPBs are (unordered) sets of GPUs.
  

3.1.2 Data Dependence Between GPUs. We use the usual notion of data dependence based on Bernstein's conditions [3]: two statements have a data dependence between them if they access the same memory location and at least one of them writes into the location [19, 28]. However, we restrict ourselves to locations that are pointers and use more intuitive names such as read-after-write, write-after-write, and write-after-read for flow, output, and anti dependence, respectively.

Formally, suppose $\text{$\gamma $} _1:x \mathop {\longrightarrow }\limits _{s}^{i|j} y$ is followed by $\text{$\gamma $} _2:w\mathop {\longrightarrow }\limits _{\text{$t$}}^{k|l}z$ on some control flow path. Then, $\text{$\gamma $} _2$ has the following dependence on $\text{$\gamma $} _1$ in the following cases (note that $i,k\gt 0$ and $j,l \ge 0$ in all cases):

• WaW: $(w=x \wedge k=i)$
  
• WaR: $(w=x \wedge k\lt i) \vee (w=y \wedge k\le j)$
  
• RaW: $(w=x \wedge k\gt i) \vee (z=x \wedge l\ge i).$
  

Note that putting $i=j=k=l=1$ reduces to the classical definitions of these dependences.

We call these dependences definite dependences. They correspond to case A.i in Section 1.2. In addition, if $\text{$\gamma $} _2$ postdominates $\text{$\gamma $} _1$ (i.e., follows $\text{$\gamma $} _1$ on every control flow path), we call the dependence strict. As illustrated in Example 1, $\text{$\gamma $} _1$ and $\text{$\gamma $} _2$ can have a dependence even when they do not have a common variable. Such a dependence is called a potential dependence (case B in Section 1.2).

Two GPUs on a control flow path cannot be placed within a single GPB if there is a definite or potential RaW or WaW dependence between them. However, it is safe to include them in the case of WaR dependence because of the “all reads precede all writes” semantics of GPBs.

In this section, we intuitively describe GPU composition and GPU reduction.

The GPG of procedure $R$ (denoted $\text{$\Delta $} _R$) is constructed by traversing a spanning tree of the call graph starting with its leaf nodes. It involves the following steps:

1. creation of the initial GPG and inlining optimized GPGs of called procedures within $\text{$\Delta $} _R$,
   
2. strength reduction optimization to simplify the GPUs in $\text{$\Delta $} _R$ by performing reaching GPUs analyses and transforming GPBs using GPU reduction,
   
3. dead GPU elimination to remove redundant GPUs in a GPG (their presence may hinder control flow minimization because of WaW dependences), and
   
4. control flow minimization to improve the compactness of $\text{$\Delta $} _R$.
   

We illustrate these steps intuitively using the motivating example in Figure 2.

3.3.1 Creating a GPG and Call Inlining. To construct a GPG from a CFG, we first map the CFG naively into a GPG by the following transformations:

• Non-pointer assignments and condition tests are removed by treating the former as empty statements and the latter as non-deterministic control flow.
  
• Each pointer assignment, labeled $s$, in the CFG is transliterated to a GPU $x \mathop {\longrightarrow }\limits _{s}^{i|j} y$, following Figure 3. If earlier compiler stages have broken compound C assignments such as $*\!*p = *\!*\!*q;$ into a sequence of simpler SSA-form intermediate-language assignments using temporaries as in Equation (1), then compound statements are reconstructed by following def-use chains to eliminate such temporaries.
  
• A GPG node $\text{$n$}$ is created for each such assignment with its GPB, $\text{$\delta $} _{n}$, being the singleton set containing this GPU and with its associated may-definition set, $\text{$\mu $} _{n}$, being empty.
  
• The control flow between GPBs is induced from their order within a basic block in the CFG and from the control flow edges of the CFG.
  
• The procedure calls are replaced by the optimized GPGs of the callees. Every time we inline a GPG, we must take a fresh copy of its nodes, here achieved by simple renumbering. Note that the statement labels $\text{$s$}$ appearing within GPUs are not renumbered.
  

Example 8. The initial GPG for procedure $Q$ of Figure 2 is given in Figure 4. Each assignment is replaced by its corresponding GPU. The initial GPG for procedure $R$ is shown in Figure 5 with the call to procedure $Q$ on line 09 replaced by its optimized GPG.

Examples 9 through 12 explain the analyses and optimizations over $\text{$\Delta $} _Q$ and $\text{$\Delta $} _R$ (GPGs for procedures $Q$ and $R$) at an intuitive level.

Fig. 4. Constructing the GPG for procedure $Q$ (see Figure 2). Strength reduction of GPB $\text{$\delta $} _{02}$ causes a weak update by defining two sources $(b,1)$ and $(q,2)$. This is captured by the may-definition sets $\text{$\mu $} _{02}$ (after strength reduction) and $\text{$\mu $} _{11}$ (after control flow minimization) being $\lbrace (b,1),(q,2)\rbrace$. Pictorially, we use rectangles rather than circles to mark may-defined sources.

Fig. 5. Constructing the GPG for procedure $R$ (see Figures 2 and 4). GPBs $\text{$\delta $} _{13}$ through $\text{$\delta $} _{14}$ in the GPG are the (renumbered) GPBs representing the inlined optimized GPG of procedure $Q$.

3.3.3 Dead GPU Elimination. The following example illustrates dead GPU elimination in our motivating example. This optimization removes the WaW dependences where possible.

Example 10. In procedure $Q$ of Figure 4, pointer $q$ is defined in $\text{$\delta $} _{03}$ but is redefined in $\text{$\delta $} _{05}$ and hence GPU ${q}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}$ is eliminated. Therefore, GPB $\text{$\delta $} _{03}$ becomes empty and is removed from $\text{$\Delta $} _Q$. Since GPU ${q}\mathop {\longrightarrow }\limits _{02}^{2|0}{m}$ does not define $q$ but its pointee, it is not killed by $\text{$\delta $} _{05}$ and is not eliminated from $\text{$\Delta $} _Q$.

For procedure $R$ in Figure 5, GPU ${q}\mathop {\longrightarrow }\limits _{07}^{1|0}{d}$ in $\text{$\delta $} _{07}$ is killed by GPU ${q}\mathop {\longrightarrow }\limits _{05}^{1|0}{e}$ in $\text{$\delta $} _{14}$. Hence, GPU ${q}\mathop {\longrightarrow }\limits _{07}^{1|0}{d}$ is eliminated from GPB $\text{$\delta $} _{07}$. Similarly, GPU ${e}\mathop {\longrightarrow }\limits _{04}^{1|1}{c}$ in GPB $\text{$\delta $} _{14}$ is removed because $e$ is redefined by GPU ${e}\mathop {\longrightarrow }\limits _{10}^{1|0}{o}$ in GPB $\text{$\delta $} _{10}$ (after strength reduction in $\text{$\Delta $} _R$). However, GPU ${d}\mathop {\longrightarrow }\limits _{08}^{1|0}{n}$ in GPB $\text{$\delta $} _{08}$ is not removed even though $\text{$\delta $} _{13}$ contains a definition of $d$ expressed GPU ${d}\mathop {\longrightarrow }\limits _{02}^{1|0}{m}$. This is because $\text{$\delta $} _{13}$ also contains GPU ${b}\mathop {\longrightarrow }\limits _{02}^{1|0}{m,}$ which defines $b$. Since statement 02 defines two sources, both of them are may-defined in $\text{$\delta $} _{13}$ (i.e., are included in $\text{$\mu $} _{13}$). Thus, the previous definition of $d$ cannot be killed—giving a weak update.

Fig. 6. The big picture of GPG construction.The arrows show the dependence between specific instances of optimizations, analyses, operations, and abstractions. The labels in parentheses refer to relevant sections.

Figure 6 provides the big picture of GPG construction by listing specific abstractions, operations, dataflow analyses, and optimizations and shows dependences between them, along with the section that define them. The optimizations use the results of dataflow analyses. The reaching GPUs analysis uses the GPU operations that are defined in terms of key abstractions. The abstractions of allocation sites, indirection lists ( indlist s), and $k$-limiting (required for extending the analysis to structures, unions, and heap) are left to the appendix.

Strength reduction optimization uses the knowledge of a producer GPU , to simplify a consumer GPU (on a control flow path from ) through an operation called GPU composition denoted (Section 4.2). A consumer GPU may require multiple GPU compositions to reduce it to an equivalent GPU with indlev $1|0$ (a classical points-to edge). This is achieved by GPU reduction that involves a series of GPU compositions with appropriate producer GPUs in $\mathcal {R}$ to simplify the consumer GPU maximally. The set $\mathcal {R}$ of GPUs used for simplification provides a context for and represents generalized points-to knowledge from previous GPBs. It is obtained by performing a dataflow analysis called the reaching GPUs analysis (Sections 4.5, and 4.6), which computes the sets ${{\text RGIn}$_{\text{$n$}}$}$, ${{\text RGOut}$_{\text{$n$}}$}$, ${{\text RGGen}$_{\text{$n$}}$}$, and ${{\text RGKill}$_{\text{$n$}}$}$ for every GPB $\text{$\delta $} _{\text{$n$}}$. These dataflow variables represent the GPUs reaching the entry of GPB $\text{$\delta $} _{\text{$n$}}$, its exit, the GPUs obtained through GPU reduction, and the GPUs whose propagation is killed by $\text{$\delta $} _{\text{$n$}}$, respectively. The set ${{\text RGGen}$_{\text{$n$}}$}$ is semantically equivalent to $\text{$\delta $} _{\text{$n$}}$ in the context of RGIn $_{\text{$n$}}$ and may beneficially replace $\text{$\delta $} _{\text{$n$}}$ .

Fig. 7. GPU composition .

In some cases, the location read by could be different from the location defined by due to the presence of a GPU (called a barrier) corresponding to an intervening assignment. This could happen because of a potential dependence between and . (Section 2.2). In such a situation (characterized formally in Section 4.6.1), replacing $\text{$\delta $} _{\text{n}}$ by ${{\text RGGen}$_{\text{$n$}}$}$ during strength reduction may be unsound. Hence we postpone the composition explicitly by eliminating those GPUs from $\mathcal {R}$ that are blocked by a barrier. After inlining, the knowledge of the calling context may allow a barrier GPU to be reduced so that it no longer blocks a postponed reduction.

We first present the intuition behind GPU composition before defining it formally.

4.2.1 The Intuition Behind GPU Composition. The composition of a consumer GPU and a producer GPU is possible when has a RaW dependence on through a common variable called the pivot of composition. It is the source of but may be the source or the target of .

The type ${\tau }$ of composition indicates the name of the composition, which is TS or SS ,where the first letter indicates the role of the pivot in and second letter indicates its role in . For a TS composition, the pivot is the target of ( T for target) and the source of ( S for source), whereas for SS composition, pivot is the source of both and . Note that TS and SS compositions are mutually exclusive for a given pair of and because the same variable cannot occur both in the RHS and LHS of an assignment in the case of pointers to scalars.⁷

Definition 3. Composing a consumer GPU with a producer GPU to compute a new GPU that is equivalent to in the context of . Both SS and TS compositions exploit a RaW dependence of statement labeled $t$ on the statement labeled $s$ because the pointer defined in is used to simplify a pointer used in .

Figure 7 illustrates these compositions. For TS composition, consider $\!:\!$ ${z}\mathop {\longrightarrow }\limits _{\text{$t$}}^{i|j}{x}$ and $\!:\!$ ${x}\mathop {\longrightarrow }\limits _{\text{$s$}}^{k|l}{y}$ with pivot $x,$ which is the target of and the source of . The goal of the composition is to join the source $z$ of and the target $y$ of by using the pivot $x$ as a bridge. This requires the indlev s of $x$ to be made the same in the two GPUs. For example, if $j \ge k$ (other cases are explained later in the section), this can be achieved by adding $j-k$ to the indlev s of the source and target of to view the base GPU in its derived form as ${x}\stackrel{\longrightarrow }{j|(l+j-k)}{y}$. This balances the indlev s of $x$ in the two GPUs, allowing us to create a simplified GPU .

4.2.2 Defining GPU Composition. Before we define the GPU composition formally, we need to establish the properties of validity and desirability that allow us to characterize meaningful GPU compositions. We say that a GPU composition is admissible if and only if it is valid and desirable :

1. A composition is valid only if has a RaW dependence on through the pivot of the composition.
   
2. A composition is desirable only if the indlev of does not exceed the indlev of .
   

Validity requires the indlev of the pivot in to be greater than the indlev of pivot in . For the generic indlev s used in Figure 7, this requirement translates to the following constraints:

\begin{align} j \ge k & & ({\sf TS} \text{ composition}) \end{align} (2)

\begin{align} i \gt k & & ({\sf SS} \text{ composition}) \end{align} (3)

Observe that SS composition condition (3) prohibits equality because it involves the source nodes of both the GPUs. When $i=k$, has WaW dependence on instead of RaW dependence (Section 3.1.2) because overwrites the location written by .

The desirability of GPU composition characterizes progress in conversion of GPUs into classical points-to edges by ensuring that the indlev of the new source and the new target in does not exceed the corresponding indlev in the consumer GPU . This requires the indlev in the simplified GPU and the consumer GPU to satisfy the following constraints. In each constraint, the first term in the conjunct compares the indlev s of the sources of and , whereasthe second term compares those of the targets (see Figure 7):

\begin{align} (i \le i)\; \wedge \; (l+j-k \le j) & \quad \mbox{or equivalently} \quad l \le k \;\; & ({\sf TS} \text{ composition}), \end{align} (4)

\begin{align} (l+i-k \le i)\; \wedge \; (j \le j) & \quad \mbox{or equivalently} \quad l \le k \;\; & ({\sf SS} \text{ composition}). \end{align} (5)

Example 13. Consider the statement sequence $x=*y; z = x$. A TS composition of the corresponding GPUs and is valid because $j = k = 1,$ satisfying Constraint 2. However, if we perform this composition, we get . Intuitively, this GPU is not useful for computing a points-to edge because the indlev of is “$1|2,$” which is greater than the indlev of ,which is “$1|1.$” Formally, this composition is flagged undesirable because $l=2,$ which is greater than $k=1,$ violating Constraint 4.

We take a conjunction of the constraints of validity (2 and 3) and desirability (4 and 5) to characterize admissible GPU compositions:

\begin{align} l \le k \le j &\qquad\qquad\qquad\qquad\quad ({\sf TS} \text{composition),} \end{align} (6)

\begin{align} l \le k \lt i &\qquad\qquad\qquad\qquad\quad ({\sf SS} \text{composition).} \end{align} (7)

Note thatan undesirable GPU composition in a GPG is valid but inadmissible . It will eventually become desirable after the producer GPU is simplified further through strength reduction optimization after the GPG is inlined in a caller's GPG.

Definition 3 defines GPU composition formally. It computes a simplified GPU by balancing the indlev of the pivot in both the GPUs provided the composition ( TS or SS ) is admissible . Otherwise, it fails—being a partial operation.

Definition 4. GPU reduction .

GPU reduction uses the GPUs in $\mathcal {R}$ (a set of data-dependence-free GPUs) to compute a set of GPUs whose indlev s do not exceed that of . During reduction, the indlev of is reduced progressively using the GPUs from $\mathcal {R}$ through a sequence of admissible GPU compositions. A GPU resulting from GPU reduction is called a simplified GPU.

Formally, ${\sf Red}$ is the fixed point of the equation ${\sf Red} = {\sf \text{GPU} \!\!\_\text{reduction}} ({\sf Red}, \text{$\mathcal {R}$})$ with the initialization . Function ${\sf \text{GPU} \!\!\_\text{reduction}}$ (Definition 4) simplifies the GPUs in ${\sf Red}$ by composing them with those in $\mathcal {R}$. The resulting GPUs are accumulated in ${\sf Red}^{\prime },$ which is initially $\emptyset$. If a GPU $\text{$\gamma $} _1 \in {\sf Red}$ is simplified, its simplified GPU $r$ is included in temp, which is then added to ${\sf Red}^{\prime }$. However, if $\text{$\gamma $} _1$ cannot compose with any GPU in $\mathcal {R}$, then $\text{$\gamma $} _1$ is then added to ${\sf Red}^{\prime }$. The GPUs in ${\sf Red}^{\prime }$ are then simplified in the next iteration of the fixed-point computation. The fixed point is achieved when no GPU in ${\sf Red}^{\prime }$ can be simplified any further.

GPU reduction requires the set $\mathcal {R}$ to satisfy following properties:

• Reduced form: GPUs in $\mathcal {R}$ must be in their reduced form. Consider the GPU ${x}\mathop{\longrightarrow}\limits^{i|j}{y}$. Then,
  
  • either $i=1$ or $x$ is live on entry (represented by a special variable $x^{\prime }$), and
    
  • either $j=0$ or $y$ is live on entry (represented by a special variable $y^{\prime }$).
    
  The special variables are explained in Section 4.4.
  
• Acyclicity: The graph induced by the GPUs in $\mathcal {R}$ should be acyclic. $\mathcal {R}$ cannot have a subset like $\lbrace {x}\mathop{\longrightarrow}\limits^{1|1}{y}, {y}\mathop{\longrightarrow}\limits^{1|1}{x} \rbrace$. Taking the reduced form serves to replace this subset with $\lbrace {x}\mathop{\longrightarrow}\limits^{1|1}{y^{\prime }}, {y}\mathop{\longrightarrow}\limits^{1|1}{x^{\prime }} \rbrace ,$ thereby ruling out the cycles.⁸
  
• Completeness: If $\mathcal {R}$ contains a GPU ${x}\mathop{\longrightarrow}\limits^{i|j}{y}$, then the source $(x,i)$ must be defined along all paths reaching the GPB that is undergoing reduction. If $x$ is the pivot of composition with but $(x,i)$ is not defined along some path, it means that the simplification of is not complete and ${\sf Red}$ cannot replace . This is ensured by the introduction of boundary definitions in Section 4.4. Example 21 in Section 4.6 illustrates why completeness of $\mathcal {R}$ is required.
  
• Absence of data dependence: GPUs in $\mathcal {R}$ should not have a data dependence between them. This is preserved by reaching GPUs analyses (Sections 4.5 and 4.6). If GPU $\text{$\gamma $} _2 \in \text{$\mathcal {R}$}$ had a RaW dependence on GPU $\text{$\gamma $} _1 \in \text{$\mathcal {R}$}$, then $\text{$\gamma $} _1$ would have been simplified during reaching GPUs analysis; if $\text{$\gamma $} _2$ had a WaW dependence on $\text{$\gamma $} _1$ along a control flow path, $\text{$\gamma $} _2$ would be killed during reaching GPUs analysis along the path. Finally, if $\text{$\gamma $} _2$ had a potential dependence on $\text{$\gamma $} _1$, $\text{$\gamma $} _2$ would have been blocked and not included in $\mathcal {R}$.
  

These properties also hold for Red and are preserved by both variants of reaching GPUs analyses (Sections 4.5 and 4.6) both before and after coalescing (Section 6).

The convergence of reduction on a unique solution is guaranteed by the following:

• The indlev s in the GPUs in Red in step $i+1$ are smaller than the indlev s in the GPUs in step $i$ and the number of GPUs is finite (Section 3.1.3). Since there are no cycles in $\mathcal {R}$, once a GPU $\gamma$ is simplified, further simplifications cannot recreate $\gamma$ again; hence, there is no oscillation across the iterations of fixed-point computation, ensuring the termination of GPU reduction.
  
• The order in which GPU $\text{$\gamma $} _2$ is selected from $\mathcal {R}$ for composition with $\text{$\gamma $} _1$ does not matter because the GPUs in $\mathcal {R}$ do not have a data dependence between them.
  

Recall that for an indirect assignment ($*p=\&x$ say) as a consumer, GPU reduction typically returns a set of GPUs that define multiple abstract locations, leading to a weak update. Sometimes, however, we may discover that $p$ has a single pointee within the procedure and the assignment defines only one abstract location. In this case, we may, in general, perform a strong update. However, this condition, although necessary, is not sufficient for a strong update because the source of $p$ may not be defined along all paths—there may be a path along which the source of $p$ is not defined within the procedure (i.e., is live on entry to the procedure) and is defined in a caller. In the presence of such a definition-free path in a procedure, even if we find a single pointee of $p$ in the procedure, we cannot guarantee that a single abstract location is being defined. This makes it difficult to distinguish between strong and weak updates.

A control flow path $\text{$n$} _1,\text{$n$} _2,\ldots \text{$n$} _{k}$ in $\Delta$ is a definition-free path for source $(x,i)$ if

• no node $\text{$n$} _i$, $1 \le i \le k$, kills (Definition 5) or blocks (Definition 7) GPUs with source $(x,i)$,
  
• node $\text{$n$} _1$ is either Start $_{}$ or has a predecessor that kills or blocks $(x,i)$, and
  
• node $\text{$n$} _k$ is either End $_{}$ or has a successor that kills or blocks $(x,i)$.
  

We identify the definition-free paths by introducing boundary definitions (explained in the following)

• in RGIn $_{}$ of Start $_{}$ for global variables and formal parameters, and
  
• in RGOut $_{}$ of the nodes that block some GPUs for the sources of the blocked GPUs.
  

This ensures the property of completeness of reaching GPUs (Section 4.3) that guarantees that some definition of every source $(x,i)$ reaches every node, thereby enabling strength reduction and distinguishing between strong and weak updates.

The boundary definitions are of the form ${x}\mathop {\longrightarrow }\limits _{0}^{i|i}{x^{\prime },}$ where $x^{\prime }$ is a symbolic representation of the initial value of $x$ at the start of the procedure and $i$ ranges from 1 to the maximum depth of the indirection level that depends on the type of $x$ (e.g., for type (int $**$), $i$ ranges from 1 to 2). Variable $x^{\prime }$ is called the upwards-exposed [22] version of $x$. This is similar to Hoare-logic style specifications in which postconditions use (immutable) auxiliary variables $x^{\prime }$ to denote the original value of variable $x$ (which may have since changed). Our upwards-exposed versions serve a similar purpose; logically on entry to each procedure, the statement $x = x^{\prime }$ provides a definition of $x$. The rationale behind the label 0 in the boundary definitions is explained after the following example.

Definition 5. Dataflow equations for reaching GPUs analysis without blocking.

The boundary definitions are symbolic in that they are never contained in any GPB but are only contained in the set of producer GPUs that reach the GPBs. This allows us to use a synthetic label 0 in them because only the labels of consumer GPUs matter (because they identify a source-language statement); the labels of producer GPUs are irrelevant because they only provide information that is used for simplifying consumer GPUs labeled $s$ into one or more GPUs all labeled $s$. The boundary definitions participate in GPU reduction algorithm (without requiring any change in GPU composition) like any other producer GPU. After GPU reduction, upwards-exposed versions of variables can appear in simplified GPUs.

In this section, we define reaching GPUs analysis ignoring the effect of barriers.

The reaching GPUs analysis is an intraprocedural forward dataflow analysis in the spirit of the classical reaching definitions analysis. Its dataflow equations are presented in Definition 5. They compute set RGIn $_{\text{$n$}}$ of GPUs reaching a given GPB $\text{$\delta $} _{\text{$n$}}$ by combining the GPUs in RGOut $_{\text{$m$}}$ of the predecessor GPBs $\text{$\delta $} _{\text{$m$}}$. RGIn $_{\text{$n$}}$ is then used to reduce the GPUs in $\text{$\delta $} _{\text{$n$}}$ to compute RGGen $_{\text{$n$}}$,which is semantically equivalent to $\text{$\delta $} _{\text{$n$}}$ (except for the effect of blocking) but with the additional property that the indlev s of GPUs in RGGen $_{\text{$n$}}$ do not exceed those of the corresponding GPUs in $\text{$\delta $} _{\text{$n$}}$.

RGKill $_{\text{$n$}}$ contains the GPUs that are to be excluded from RGOut $_{\text{$n$}}$ because of a strong update. A GPU in $\text{$\gamma $}^{\prime }$ from RGIn $_{\text{$n$}}$ is included in RGKill $_{\text{$n$}}$ if its source $(x,i)$ matches the source of a reduced GPU $\text{$\gamma $} \in \text{$\delta $} \vert _{\text{s}} \subseteq {{\text RGGen}$_{\text{$n$}}$}$ corresponding to some statement $s$ (identified by ${\sf Match} (\text{$\gamma $},{{\text RGIn}$_{\text{$n$}}$})$) provided:

1. All GPUs in $\text{$\delta $} \vert _{\text{s}}$ define the same source $(x,i)$. Condition $|{\sf Def} (X, \text{$\gamma $})|=1$ for ${\sf Kill} (X,\text{$\mathcal {R}$})$ in Definition 5 ensures this where ${\sf Def} (X, \text{$\gamma $})$ extracts the sources of GPUs of the same statement.
   
2. Variable $x$ in $(x,i)$ is not an upwards-exposed version $z^{\prime }$ because then $i\gt 1$ and $z^{\prime }$ could point to multiple pointees in the caller (note that an upwards-exposed version can appear in the source of a reduced GPU only if the GPU represents an indirect assignment).
   
3. Source $(x,i)$ is not in $\text{$\mu $} _{\text{n}}$.
   

If any of these conditions is violated, then $\text{$\gamma $}^{\prime }$ is excluded from RGKill $_{\text{$n$}}$, leading to weak update. Note that the GPUs that are killed are determined by the GPUs in RGGen $_{\text{$n$}}$ and not those in $\text{$\delta $} _{\text{$n$}}$.

Fig. 8. The dataflow information computed by reaching GPUs analysis for procedure $Q$ of Figure 2.

This section extends the reaching GPUs analysis to incorporate the effect of blocking by defining a dataflow analysis that computes $\overline{{\sf RGIn}}_{}$ and $\overline{{\sf RGOut}}_{}$ for the purpose.

4.6.1 The Need of Blocking.

Fig. 9. Risk of unsoundness in GPU reduction caused by a barrier GPU.

Consider the possibility of the composition of a consumer GPU that appears to have a RaW dependence on a producer GPU because they have a pivot but there is a barrier GPU (Sections 2.2 and 4.1) between the two such that has a potential WaW dependence on . This possible if the indlev of the source of or is greater than 1. We call such a GPU an indirect GPU. The execution of may alter the apparent dependence between and ,and hence the composition of with may be unsound.

Since this potential dependence between and cannot be resolved without the alias information in the calling context, we block such producer GPUs so that such GPU compositions leading to potentially unsound strength reduction optimization are postponed. Wherever possible, we use the type information to rule out some GPUs as barriers. After inlining the GPG in a caller, more information may become available. Thus, it may resolve potential data dependence of a barrier with a producer. Then, if a consumer still has a RaW dependence on a producer, the composition that was earlier postponed may now safely be performed.

Example 17. Consider the procedure in Figure 9(a). The composition of the GPUs for statements 02 and 04 is admissible . However, statement 03 may cause a side effect by indirectly defining $y$ (if $x$ points to $y$ in the calling context). Thus, $q$ in statement 04 would point to $b$ if $x$ points to $y$; otherwise, it would point to $a$. If we replace the GPU ${q}\mathop {\longrightarrow }\limits _{04}^{1|1}{y}$ by ${q}\mathop {\longrightarrow }\limits _{04}^{1|0}{a}$ (which is the result of composing ${q}\mathop {\longrightarrow }\limits _{04}^{1|1}{y}$ with ${y}\mathop {\longrightarrow }\limits _{02}^{1|0}{a}$), then we would miss the GPU ${q}\mathop {\longrightarrow }\limits _{04}^{1|0}{y}$ if $x$ points to $y$ in the calling context—leading to unsoundness. Since the calling context is not available during

GPG construction and optimization, we postpone this composition to eliminate the possibility of unsoundness. Reaching GPUs analysis with blocking blocks the GPU ${y}\mathop {\longrightarrow }\limits _{02}^{1|0}{a}$ by a barrier ${x}\mathop {\longrightarrow }\limits _{03}^{2|0}{b}$. This corresponds to the first case described earlier.

For the second case, consider statement 02 of the procedure in Figure 9(b), which may indirectly define $y$ (if $x$ points to $y$). Statement 03 directly defines $y$. Thus, $q$ in statement 04 would point to $b$ if $x$ points to $y$; otherwise, it would point to $a$. We postpone the composition with by blocking the GPU (here, the GPU ${y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}$ acts as a barrier).

Consider a GPU originally blocked by a barrier . After inlining the GPG in its callers and performing reductions in the calling contexts, the following situations could arise:

1. The indlev of the source of the indirect GPU ( or ) is reduced to 1, thereby eliminating the potential dependence. In this case, ceases being a barrier and thus no longer blocks ,leading to the following two situations:
   
   1. has a WaW dependence on and therefore redefines the pointer defined by , killing , thereby obviating the composition .
      
   2. does not have a dependence on , thereby allowing the composition .
      
2. The indlev of the source of the indirect GPU ( or ) remains greater than 1. In this case, continues to block awaiting further inlining.
   

Example 18. The preceding Case 1(a) could arise if $x$ points to $p$ in the calling context of the procedure in Figure 9(a). As a result, GPU ${y}\mathop {\longrightarrow }\limits _{02}^{1|0}{a}$ is killed by the barrier GPU ${y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}$ (which is the simplified version of the barrier GPU ${x}\mathop {\longrightarrow }\limits _{03}^{2|0}{b}$), and hence the composition is prohibited and $q$ points to $b$ for statement 04. Case 1(b) could arise if $x$ points to any location other than $y$ in the calling context. In this case, the composition between ${q}\mathop {\longrightarrow }\limits _{04}^{1|1}{y}$ and ${y}\mathop {\longrightarrow }\limits _{02}^{1|0}{a}$ is sound, and $q$ points to $a$ for statement 04. Case 2 could arise if the pointee of $x$ is not available even in the calling context. In this case, the barrier GPU ${x}\mathop {\longrightarrow }\limits _{03}^{2|0}{b}$ continues to block ${y}\mathop {\longrightarrow }\limits _{02}^{1|0}{a}$.

Our measurements (Section 10) show that situation 1(a) rarely arises in practice because it amounts to defining the same pointer multiple times through different aliases in the same context.

Example 19. To see how reaching GPUs analysis with blocking helps, consider the example in Figure 9(b). The set of GPUs reaching the statement 04 is ${{\text RGIn}$_{04}$} = \lbrace {x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a}, {y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}\rbrace$. The GPU ${x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a}$ is blocked by the barrier GPU ${y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b,}$ and hence $\text{$\overline{{\sf RGIn}}_{04}$} = \lbrace {y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}\rbrace$. Thus, GPU reduction for $\text{$\gamma $} _1 \!:\! {q}\mathop {\longrightarrow }\limits _{04}^{1|2}{x}$ (in the context of $\text{$\overline{{\sf RGIn}}_{04}$}$) computes Red as $\lbrace \text{$\gamma $} _1\rbrace$ because $\text{$\gamma $} _1$ cannot be reduced further within the GPG of the procedure. However, $\text{$\gamma $} _1$ is still not a points-to edge and can be simplified further after the GPG is inlined in its callers. Hence, we postpone the composition of $\text{$\gamma $} _1$ with until has been simplified.

4.6.2 Dataflow Equations for Computing $\overline{{\sf RGIn}}_{}$ and $\overline{{\sf RGOut}}_{}$.

Definition 6. Blocking.

Definition 7. Dataflow equations for reaching GPUs analysis with blocking.

The following GPUs should be blocked as barriers:

• If $\overline{{\sf RGGen}}_{\text{$n$}}$ contains a GPU , then all GPUs reaching $\text{$\delta $} _{\text{$n$}}$ that share a data dependence with should be blocked regardless of the nature of other GPUs (if any) in $\overline{{\sf RGGen}}_{\text{$n$}}$.
  
• If $\overline{{\sf RGGen}}_{\text{$n$}}$ does not contain an indirect GPU and is not $\emptyset$, then all indirect GPUs reaching $\text{$\delta $} _{\text{$n$}}$ that share a data dependence with a GPU in $\overline{{\sf RGGen}}_{\text{$n$}}$ should be blocked.
  

Additionally, we use the type information to minimize blocking. We define a predicate $\text{$\overline{{\sf DDep}}$} (B, I)$ to check the presence of data dependence between the sets of GPUs $B$ and $I$ (Definition 6). When the types of and match, we assume the possibility of data dependence and hence blocks . ${\sf TDef} (B)$ is the set of types of locations being written by a barrier, whereas $\left({\sf TDef} (I) \cup {\sf TRef} (I)\right)$ represents the set of types of locations defined or read by the GPUs in $I,$ thereby checking for a potential WaW and WaR dependence of the GPUs in $B$ on those of $I$.

The dataflow equations in Definition 7 differ from those in Definition 5 as follows:

• $\overline{{\sf RGKill}}_{\text{$n$}}$ additionally includes blocked GPUs computed using function ${\sf Blocked} (I,G)$. The latter examines the GPUs in $\overline{{\sf RGGen}}_{\text{$n$}}$ (argument “$G$” for generated) to identify the GPUs in $\overline{{\sf RGIn}}_{\text{$n$}}$ (argument “$I$” for incoming) that should be blocked using three cases that exhaust all possibilities:
  
  • Case 1 corresponds to not blocking any GPU because $\overline{{\sf RGGen}}_{\text{$n$}}$ is empty.
    
  • Case 2 corresponds to blocking some GPUs because $\overline{{\sf RGGen}}_{\text{$n$}}$ contains an indirect GPU.
    
  • Case 3 corresponds to blocking indirect GPUs because $\overline{{\sf RGGen}}_{\text{$n$}}$ does not contain an indirect GPU and is not $\emptyset$.
    
• $\overline{{\sf RGOut}}_{\text{$n$}}$ explicitly introduces boundary definitions for the GPUs that are blocked. This is essential for ensuring the completeness of the set of reaching GPUs (Section 4.3) that is necessary for replacing $\text{$\delta $} _{\text{n}}$ by $\overline{{\sf RGGen}}_{\text{$n$}}$. This is possible because of the following property of upwards-exposed versions: any read of $x$ anywhere in the procedure can be replaced by $x^{\prime }$ without affecting soundness or precision because there is no GPU with $(x^{\prime },i)$ as its source. Hence, a statement $*x^{\prime }=\&a$ does not have a RaW dependence on any statement, and the occurrences of $x^{\prime }$ cannot be simplified any further. After inlining in the caller, $x^{\prime }$ is replaced by $x$ and hence the statement reverts to its original form.
  

Example 20. For the procedure in Figure 9(b), $\text{$\overline{{\sf RGIn}}_{02}$} = \emptyset$ and $\text{$\overline{{\sf RGGen}}_{02}$}$ is $\lbrace {x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a}\rbrace$. Although $\overline{{\sf RGGen}}_{02}$ contains an indirect GPU, since no GPUs reach 02 (because it is the first statement), $\overline{{\sf RGOut}}_{02}$ is $\lbrace {x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a}\rbrace ,$ indicating that no GPUs are blocked.

For statement 03, $\text{$\overline{{\sf RGIn}}_{03}$} = \lbrace {x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a}\rbrace$ and $\text{$\overline{{\sf RGGen}}_{03}$} = \lbrace {y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}\rbrace$. $\overline{{\sf RGGen}}_{03}$ is non-empty and does not contain an indirect GPU, and thus $\text{$\overline{{\sf RGOut}}_{03}$} = \lbrace {y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}\rbrace$ according to the third case in the Blocked equation in Definition 7, indicating that the GPU ${x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a}$ is blocked and should not be used for composition by the later GPUs. The indirect GPU in $\overline{{\sf RGIn}}_{03}$ is excluded from $\overline{{\sf RGOut}}_{03}$. Note that the indirect GPU ${x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a}$ is blocked by the GPU ${y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}$ because ${\sf typeof} (x, 2)$ matches with ${\sf typeof} (p, 1),$ indicating a possibility of WaW dependence.

For statement 04, $\text{$\overline{{\sf RGIn}}_{04}$} = \lbrace {y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}\rbrace$ and $\overline{{\sf RGGen}}_{04}$ is $\lbrace {q}\mathop {\longrightarrow }\limits _{04}^{1|2}{x}\rbrace$. For this statement, the composition $({q}\mathop {\longrightarrow }\limits _{04}^{1|2}{x} \text{$\ \circ \ $} ^{\textrm {ts}} {x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a})$ is postponed because the GPU ${x}\mathop {\longrightarrow }\limits _{02}^{2|0}{a}$ is blocked. In this case, $\overline{{\sf RGGen}}_{04}$ does not contain an indirect GPU and $\text{$\overline{{\sf RGOut}}_{04}$} = \lbrace {y}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}, {q}\mathop {\longrightarrow }\limits _{04}^{1|2}{x}\rbrace$.

In Figure 9(a), the GPU ${y}\mathop {\longrightarrow }\limits _{02}^{1|0}{a}$ is blocked by the barrier GPU ${x}\mathop {\longrightarrow }\limits _{03}^{2|0}{b}$ because ${\sf typeof} (y, 1)$ matches with ${\sf typeof} (x, 2)$. Hence, the composition $({q}\mathop {\longrightarrow }\limits _{04}^{1|1}{y} \text{$\ \circ \ $} ^{\textrm {ts}} {y}\mathop {\longrightarrow }\limits _{02}^{1|0}{a})$ is postponed.

In the GPG of procedure $Q$ (of our motivating example) shown in Figure 4, the GPUs ${r}\mathop {\longrightarrow }\limits _{01}^{1|0}{a}$ and ${q}\mathop {\longrightarrow }\limits _{03}^{1|0}{b}$ are not blocked by the GPU ${q}\mathop {\longrightarrow }\limits _{02}^{2|0}{m}$ because they have different types. However, the GPU ${e}\mathop {\longrightarrow }\limits _{04}^{1|2}{p}$ blocks the indirect GPU ${q}\mathop {\longrightarrow }\limits _{02}^{2|0}{m}$ because there is a possible WaW data dependence ($e$ and $q$ could be aliased in the callers of $Q$).

Example 21 shows the role of boundary definitions in ensuring completeness of reaching GPUs.

Example 21. Let the GPUs of the statements 1, 2, and 3 on the right be denoted by $\text{$\gamma $} _1$, $\text{$\gamma $} _2$, and $\text{$\gamma $} _3$, respectively. Then, $\text{$\gamma $} _1$ is blocked by $\text{$\gamma $} _2$ because of potential RaW dependence (if $p$ points-to $x$ in the caller). Thus, $\text{$\overline{{\sf RGIn}}_{3}$}\! =\! \lbrace \text{$\gamma $} _1, \text{$\gamma $} _2 \rbrace$. Then, the $\text{$\overline{{\sf RGGen}}_{3}$}\! =\! \lbrace {y}\mathop {\longrightarrow }\limits _{3}^{1|0}{a}\rbrace$. Replacing $\text{$\delta $} _3$ by $\overline{{\sf RGGen}}_{3}$ is unsound because if $p$ points to $x$ in the caller, then $y$ should also point to $b$. The problem arises because $\overline{{\sf RGIn}}_{3}$ does not have the source $(x,1)$ defined along the path 1-2-3 because of blocking in node 2. This violates the completeness of $\overline{{\sf RGIn}}_{3}$. Explicitly adding the boundary definition ${x}\mathop {\longrightarrow }\limits _{0}^{1|1}{x^{\prime }}$ in 2 ensures that $(x,1)$ is defined along both the paths, leading to $\text{$\overline{{\sf RGGen}}_{3}$} = \lbrace {y}\mathop {\longrightarrow }\limits _{3}^{1|0}{a}, {y}\mathop {\longrightarrow }\limits _{3}^{1|1}{x^{\prime }}\rbrace$. When the resulting GPG is inlined in the caller, $x^{\prime }$ is replaced by $x$ and the original consumer GPU representing $y=x$ is recovered. Thus, if $p$ points to $x,$ then after node 3, $y$ points to both $a$ and $b$. However, if $p$ does not point to $x,$ then after node 3, $y$ points to $a$ as expected.

After strength reduction and dead GPU elimination, we coalesce multiple GPBs into a single GPB whenever possible to reduce the size of GPGs (in terms of control flow information). It relies on the elimination of data dependence by strength reduction and dead GPU elimination. This turns out to be the core idea for making GPGs a scalable technique for points-to analysis.

Strength reduction exploits and removes all definite RaW dependences, whereas dead GPU elimination removes all definite WaW dependences that are strict (Section 3.1.2). Only the potential dependences, definite WaRdependences, and definite non-strict WaW dependences remain. Recall that WaR dependences are preserved by GPBs; as we shall see in this section, definite non-strict WaW dependences are also preserved by coalesced GPBs. This make much of the control flow redundant.

For a control flow edge $\text{$\delta $} _{\text{$n$} _1}\rightarrow \text{$\delta $} _{\text{$n$} _2}$, the decision to coalesce GPBs $\text{$\delta $} _{\text{$n$} _1}$ and $\text{$\delta $} _{\text{$n$} _2}$ is influenced not only by the dependence between the GPUs of $\text{$\delta $} _{\text{$n$} _1}$ and $\text{$\delta $} _{\text{$n$} _2}$ but also by the dependence of the GPUs of $\text{$\delta $} _{\text{$n$} _1}$ and $\text{$\delta $} _{\text{$n$} _2}$ with the GPUs in some other GPB as illustrated in the following example.

The next example illustrate that a non-strict WaW dependence does not constrain coalescing.

There is no “best” coalescing operation: given three sequenced GPUs $\text{$\gamma $} _1$, $\text{$\gamma $} _2$ $\text{$\gamma $} _3$, then $\text{$\gamma $} _1$ may coalesce with $\text{$\gamma $} _2$ and separately $\text{$\gamma $} _2$ may coalesce with $\text{$\gamma $} _3$,but the GPUs $\text{$\gamma $} _1, \text{$\gamma $} _2, \text{$\gamma $} _3$ do not all coalesce.

Therefore, we formulate the coalescing operation on a GPG as a partition $\text{$\Pi $}$ on its nodes (Section 6.2), set out the correctness conditions the partition must satisfy (Section 6.3), and describe how we select one of the maximally coalescing partitions satisfying the conditions (Section 6.4).

Definition 8. Computing the may-definition sets for the nodes in $\text{$\Delta $}/\text{$\Pi $}$ during coalescing.

Recall that a partition $\text{$\Pi $}$ of a set $S$ is a collection of the non-empty subsets of $S$ such that every element of $S$ is a member of exactly one element of $\text{$\Pi $}$. We call the elements of $\text{$\Pi $}$ parts and write $\text{$\Pi $} (x)$ for the part containing $x$. A partition induces an equivalence relation on $S$; thus, for example, $x \in \text{$\Pi $} (y)$ holds if and only if $y \in \text{$\Pi $} (x)$.

Following a practice common for CFGs, we have previously conflated the idea of a node $n$ of a GPG with that of its GPB $\text{$\delta $} _{\text{n}}$ which is a set of GPUs. It is helpful to keep these separated when defining a partition, noting that, under coalescing, GPBs remain sets of GPUs while the definition of a node is changed.

Given a GPG $\text{$\Delta $}$ and a partition $\text{$\Pi $}$ on its nodes, we obtain a coalesced GPG, written $\text{$\Delta $}/\text{$\Pi $}$, in the following steps:

1. The nodes of $\text{$\Delta $}/\text{$\Pi $}$ (written ${\hat{n}}$) are sets of the nodes of $\text{$\Delta $}$. More precisely, they are the members of $\text{$\Pi $}$ and represent its equivalence classes.
   The $\mathit {entry}$ and $\mathit {exit}$ nodes of a part ${\hat{n}}$ are defined as follows:
   \begin{align*} \text{$\mathit {entry}$} ({\hat{n}}) & = \left\lbrace \text{$n$} \in {\hat{n}} \mid \exists \, \text{$n$}^{\prime } \in \text{$\mathit {pred}$} (\text{$n$}), \text{$n$}^{\prime } \notin {\hat{n}} \right\rbrace \\ \text{$\mathit {exit}$} ({\hat{n}}) & = \left\lbrace \text{$n$} \in {\hat{n}} \mid \exists \, \text{$n$}^{\prime } \in \text{$\mathit {succ}$} (\text{$n$}), \text{$n$}^{\prime } \notin {\hat{n}} \right\rbrace . \end{align*}
   
   
2. $\text{$\Delta $}/\text{$\Pi $}$ has an edge ${\hat{n}} _1 \rightarrow {\hat{n}} _2$ if ${\hat{n}} _1 \ne {\hat{n}} _2$ and $\exists \text{$n$} _1 \in {\hat{n}} _1, \text{$n$} _2 \in {\hat{n}} _2$ suchthat $\text{$n$} _1\rightarrow \text{$n$} _2$ is an edge in $\text{$\Delta $}$.
   
3. The Start $_{}$ and End $_{}$ nodes of $\text{$\Delta $}/\text{$\Pi $}$ respectively are the parts containing the Start $_{}$ and End $_{}$ nodes of $\text{$\Delta $}$.
   
4. The GPB $\text{$\delta $} _{{\hat{n}}}$ of each node ${\hat{n}}$ (which represents the part $\text{$\Pi $} (\text{$n$})$ for some $n$) is the union of the GPBs corresponding to the nodes in ${\hat{n}}$ (i.e., $\text{$\delta $} _{{\hat{n}}} = \bigcup _{\text{$n$} \in {\hat{n}}} \text{$\delta $} _{\text{n}}$).
   
5. The may-definition set $\text{$\mu $} _{{\hat{n}}}$ of each node is computed using Definition 8 as follows:
   
   • We identify the GPUs that are not modified in ${\hat{n}}$ by finding out the GPUs that reach the entry nodes of ${\hat{n}}$ (represented by the set ${\sf in{\text{GPUs}}} ({\hat{n}})$) and the exit nodes of ${\hat{n}}$ (represented by the set ${\sf out{\text{GPUs}}} ({\hat{n}})$) but are not generated within ${\hat{n}}$ (set $\text{$\delta $} _{{\hat{n}}}$).
     
   • Set $\text{$\mu $} _{\hat{n}}$ contains the sources of the preceding GPUs (represented by the set ${\sf preservedSources} ({\hat{n}})$) that are also defined within the GPB ${\hat{n}}$ (represented by the set ${\sf definedSources} ({\hat{n}})$).
     
   In essence, we compute $\text{$\mu $} _{\hat{n}}$ in terms of $\text{$\mu $} _{\text{n}}$ ($\text{$n$} \in {\hat{n}}$).
   

This is the natural definition of quotient of a labeled graph, save that self-edges are removed as they serve no purpose. Due to strength reduction, a self-loop cannot represent a control flow edge with an unresolved data dependence between the GPUs across it. There are two possibilities for a self-loop: it exists in the original program or could result from empty GPB elimination and coalescing. In the former case, strength reduction, based on the fixed point of reaching GPUs analysis, ensures that the data dependence along the self-loop is eliminated (there is no blocking as the GPUs reached along the self-loop belong to an immediate successor). In the latter case, the reduction of a loop to a self-loop indicates that there are no indirect GPUs in the loop and hence no blocking. Thus, the data dependences in the loop are eliminated through strength reduction.

Observe that for every path in $\Delta$, there is a corresponding path in $\text{$\Delta $}/\text{$\Pi $}$. In the degenerate case, this path could well be a single node ${\hat{n}}$ if all nodes along a path are coalesced into the same part.

After finding a suitable partition, we revert to our previous abuse of notation and once again conflated nodes with their GPBs representing the sets of GPUs.

A partition $\Pi$ is valid for coalescing to construct $\text{$\Delta $}/\text{$\Pi $}$ if it preserves the semantic understandings of $\text{$\Delta $}$. Validity is characterized by a set of conditions that ensures the following:

• Soundness: Every GPU that reaches the End $_{}$ GPB of $\Delta$ also reaches the End $_{}$ GPB of $\text{$\Delta $}/\text{$\Pi $}$. This must hold for both variants of reaching GPUs analysis (Sections 4.5 and 4.6) and also for the GPUs representing the boundary definitions (Section 4.4).
  
• Precision: No GPU that does not reach the End $_{}$ GPB of $\Delta$ should reach the End $_{}$ GPB of $\text{$\Delta $}/\text{$\Pi $}$. This must hold for both variants of reaching GPUs analysis and also for the GPUs representing boundary definitions.
  

Assuming that dead GPU elimination and empty GPB elimination have been performed before coalescing, the validity of a coalescing partition is formalized as the following sufficient conditions:

• Soundness:
  
  • If there is a control flow path from $\text{$n$} _1$ to $\text{$n$} _2$ ($\text{$n$} _2 \in \text{$\mathit {succ}^+$} (\text{$n$} _1)$) and $\text{$n$} _1$ and $\text{$n$} _2$ are coalesced ($\text{$n$} _2 \in \text{$\Pi $} (\text{$n$} _1)$), then we require, for all GPUs $\text{$\gamma $} _1 \in \text{$\delta $} _{\text{$n$} _1}$ and $\text{$\gamma $} _2 \in \text{$\delta $} _{\text{$n$} _2}$, that $\text{$\gamma $} _1$ and $\text{$\gamma $} _2$ have no potential RaW dependence between them.
    
  • Consider a definition-free path $\rho \!: \text{$n$} _1,\text{$n$} _2,\ldots \text{$n$} _k$ for source $(x,i)$ in $\Delta$. Then, $\text{$\Delta $}/\text{$\Pi $}$ must have a corresponding definition-free path $\hat{\rho }\!:{\hat{n}} _1,{\hat{n}} _2,\ldots {\hat{n}} _l$ such that
    
    • — If $\text{$n$} _1$ is Start $_{}$ , then ${\hat{n}} _1 = \text{$\Pi $} (\text{$n$} _1)$; otherwise, ${\hat{n}} _1 = \text{$\Pi $} (\text{$n$} _{j+1})$ such that first $j$ nodes in $\rho$ belong to $\text{$\Pi $} (\text{$n$} _0)$ where $\text{$n$} _0 \in \text{$\mathit {pred}$} (\text{$n$} _1)$ and $(x,i) \notin \text{$\mu $} _{\text{$n$} _0)}$.
      
    • — If $\text{$n$} _k$ is End $_{}$ , then ${\hat{n}} _l = \text{$\Pi $} (\text{$n$} _k)$; otherwise, ${\hat{n}} _l = \text{$\Pi $} (\text{$n$} _{l-1})$ such that last $l$ nodes in $\rho$ belong to $\text{$\Pi $} (\text{$n$} _{k+1})$ where $\text{$n$} _{k+1} \in \text{$\mathit {succ}$} (\text{$n$} _k)$ and $(x,i) \notin \text{$\mu $} _{\text{$n$} _{k+1}}$.
      
• Precision:
  
  • If there is a control flow path from $\text{$n$} _1$ to $\text{$n$} _2$ ($\text{$n$} _2 \in \text{$\mathit {succ}^+$} (\text{$n$} _1)$) and $\text{$n$} _1$ and $\text{$n$} _2$ are coalesced ($\text{$n$} _2 \in \text{$\Pi $} (\text{$n$} _1)$), then we require, for all GPUs $\text{$\gamma $} _1 \in \text{$\delta $} _{\text{$n$} _1}$ and $\text{$\gamma $} _2 \in \text{$\delta $} _{\text{$n$} _2}$, that $\text{$\gamma $} _1$ and $\text{$\gamma $} _2$ have no potential strict WaW dependence between them. Observe that definite strict WaW dependences have already been eliminated by dead GPU elimination.
    
  • For every ${\hat{n}}$ in $\text{$\Delta $}/\text{$\Pi $}$ that may-defines source $(x,i)$, there must be a control flow path $\text{$n$} _1,\text{$n$} _2,\ldots , \text{$n$} _{k-1}, \text{$n$} _k$ in $\Delta$ such that
    
    • — $\text{$n$} _1$ belongs to a predecessor of ${\hat{n}}$, $\text{$n$} _k$ belongs to a successor of ${\hat{n}}$, and
      
    • — all nodes from $\text{$n$} _2$ to $\text{$n$} _{k-1}$ belong to ${\hat{n}}$ and may-defines source $(x,i)$.
      
  • For every control flow edge ${\hat{n}} _1\rightarrow {\hat{n}} _2$ in $\text{$\Delta $}/\text{$\Pi $}$, $\Delta$ must have a control flow path from every $\text{$n$} _1 \in {\hat{n}} _1$ to every $\text{$n$} _2 \in {\hat{n}} _2$.
    

Fig. 10. Illustrating soundness and precision of coalescing ( Start $_{}$ and End $_{}$ nodes are not shown).

Condition (S1) ensures that no RaW dependence is missed in $\text{$\Delta $}/\text{$\Pi $}$; condition (S2) ensures that no strict WaW dependence is spuriously included in $\text{$\Delta $}/\text{$\Pi $}$. Together, they ensure that every GPU reaching the End $_{}$ node in $\Delta$ also reaches the End $_{}$ node of $\text{$\Delta $}/\text{$\Pi $}$.

Conditions (P1) and (P2) ensure that killing is not underapproximated in $\text{$\Delta $}/\text{$\Pi $}$ by converting a strict WaW dependence into a non-strict dependence. Although definite strict WaW dependences with GPUs have been removed, we could still have a potential strict WaW dependence between GPUs or a definite strict WaW dependence with a boundary definition. Condition (P3) ensures that no spurious RaW dependence is included in $\text{$\Delta $}/\text{$\Pi $}$. Together, they ensure that no GPU that does not reach the End $_{}$ node in $\Delta$ reaches the End $_{}$ node of $\text{$\Delta $}/\text{$\Pi $}$.

Note that coalescing only forbids nodes that have a potential RaW or WaW dependence from being coalesced if there is a control flow path between them; coalescing in the absence of data dependence (or in the presence of definite non-strict WaW dependence) is generally allowed.

Two important characteristics of these conditions are the following:

• They are sufficiency conditions in that they are stronger than actual requirements—it is possible to create examples of $\Delta$ and $\Pi$ such that $\text{$\Delta $}/\text{$\Pi $}$ do not satisfy these requirements and yet no data dependence is violated nor is a new data dependence created.
  
• They characterize the soundness and precision of coalescing but not its efficiency. Consider a trivial partitioning such that $\text{$\Pi $} (\text{$n$}) = \lbrace \text{$n$} \rbrace$ (i.e., every node is placed in a separate part). This partitioning is sound and precise but not efficient. However, there may be no potential data dependence between any of the GPUs of $\Delta$; then, all nodes may be placed in a single part. Our empirical results show that a large number of GPGs nearly fall in this category, giving us the scalability.
  

This section describes how we ensure that the conditions of validity of partitioning are satisfied.

6.4.1 Ensuring Soundness. We honor the conditions for soundness in the following manner:

1. Given a part $\text{$\Pi $} (\text{$n$})$, a node $\text{$n$} _1 \notin \text{$\Pi $} (\text{$n$})$ is considered for inclusion in $\text{$\Pi $} (\text{$n$})$ only if some predecessor or some successor of $\text{$n$} _1$ is in $\text{$\Pi $} (\text{$n$})$. This ensures that every part $\text{$\Pi $} (\text{$n$})$ is a connected subgraph.⁹
   
2. Node $\text{$n$} _1$ is included in $\text{$\Pi $} (\text{$n$})$ only if there is no potential RaW or WaW dependences¹⁰ between the GPUs $\text{$n$} _1$ and those of any node $\text{$n$} _2 \in \text{$\Pi $} (\text{$n$}) \cap \text{$\mathit {pred}^+$} (\text{$n$} _1)$.
   
3. Definition-free paths are preserved by maintaining may-definition sets, with $\text{$\mu $} _{\hat{n}}$ containing the sources that are may-defined in ${\hat{n}}$.
   

Example 30. This example illustrates why the preceding step (2) only considers the dependence between $\text{$n$} _1$ and $\text{$n$} _2 \in (\text{$\Pi $} (\text{$n$}) \cap \text{$\mathit {pred}^+$} (\text{$n$} _1))$ rather than between $\text{$n$} _1$ and $\text{$n$} _2 \in \text{$\Pi $} (\text{$n$})$. In Figure 11(a), nodes $\text{$n$} _1$, $\text{$n$} _2$, and $\text{$n$} _4$ can be included in the same part. Consider node $\text{$n$} _3$ for inclusion in this part: the GPU in $\text{$n$} _3$ appears to have RaW dependence with the GPU in node $\text{$n$} _4$ because variable $z^{\prime }$ will be replaced by $z$ after inlining $z^{\prime }$. However, there is no control flow from $\text{$n$} _4$ to $\text{$n$} _3$. Hence, the data dependence of the GPU in $\text{$n$} _3$ need only be checked with those in $\text{$n$} _1$ and $\text{$n$} _2$ and not with those in $\text{$n$} _4$. Thus, $\text{$n$} _3$ can also be included in the same part. Similarly, although it appears that there is a WaW dependence between $\text{$n$} _2$ and $\text{$n$} _5$, the latter can also be included in the same part.

Fig. 11. Illustrating data dependence check and coherence in coalescing.

6.4.4 Dataflow Analysis for Coalescing.

Definition 9. Dataflow equations for coalescing analysis.

We define two interdependent dataflow analyses that

• construct part $\text{$\Pi $} (\text{$n$})$ using data flow variables ColIn $_{\text{$n$}}$/ ColOut $_{\text{$n$}}$ and
  
• compute the GPUs reaching node $n$ (from within the nodes in $\text{$\Pi $} (\text{$n$})$) in dataflow variables GpuIn $_{\text{$n$}}$/ GpuOut $_{\text{$n$}}$. This information is used to identify the potential RaW or WaW data dependence between the GPUs in part $\text{$\Pi $} (\text{$n$})$.
  

Unlike the usual dataflow variables that typically compute a set of facts, ColIn $_{\text{$n$}}$/ ColOut $_{\text{$n$}}$ are predicates. Consider a control flow edge $\text{$\delta $} _{\text{n}} \rightarrow \text{$\delta $} _{\text{m}}$ in the GPG. Then, $m$ and $n$ belong to the same part if ColOut $_{\text{$n$}}$ and ColIn $_{\text{$m$}}$ are true . Thus, our analysis does not enumerate the parts as sets of GPBs explicitly; instead, parts are computed implicitly by setting predicates ColIn $_{}$/ ColOut $_{}$ of adjacent GPBs.

The dataflow equations to compute ColIn $_{\text{$n$}}$/ ColOut $_{\text{$n$}}$ are given in Definition 9. The initialization is false for all GPBs. Predicate ${\sf coalesce} (P, n)$ uses ${\sf gpuFlow} (P, n)$ to check if GPUs reaching $P$ from within $\text{$\Pi $} (P)$ are allowed to flow from $P$ to $n$—if yes, then $P$ and $n$ belong to the same part. If ${{\text GpuOut}$_{P}$}$ is $\emptyset$, they belong to the same part regardless of ${\sf gpuFlow} (P, n)$. The presence of ColOut $_{P}$ in the equation of coalesce (Definition 9) ensures that GPB $\text{$\delta $} _P$ is considered for coalescing with $\text{$\delta $} _{\text{n}}$ only if $\text{$\delta $} _P$ has not been found to be an $\mathit {exit}$ node of a part.

Unlike the usual dataflow equations, the dataflow variables ColIn $_{\text{$n$}}$ and ColOut $_{\text{$n$}}$ for GPB $n$ are independent of each other— ColIn $_{\text{$n$}}$ depends only on the ColOut $_{}$ of its predecessors, and ColOut $_{\text{$n$}}$ depends only on the ColIn $_{}$ of its successors. Intuitively, this form of dataflow equations attempts to melt the boundaries of GPB $n$ to explore fusing it with its successors and predecessors.

Fig. 12. An example demonstrating the effect of coalescing. The loop formed by the back edge $\text{$\delta $} _5 \rightarrow \text{$\delta $} _1$ reduces to a self-loop over GPB $\text{$\delta $} _8$ after coalescing, which is redundant (Section 6.2) and is removed.

The incremental expansion of a part in a forward direction influences the flow of GPUs accumulated in a part leading to a forward dataflow analysis for computing the GPUs reaching node $n$ in $\text{$\Pi $} (\text{$n$})$ using dataflow variables GpuIn $_{\text{$n$}}$/ GpuOut $_{\text{$n$}}$. The dataflow equations to compute them are given in Definition 9. Function ${\sf gpuFlow} (p, n)$ in the equation for GpuIn $_{}$ computes the set of GPUs reaching $p$ in $\text{$\Pi $} (p)$ that flow from $p$ to $n$ (provided $n$ can be included in $\text{$\Pi $} (p)$). It facilitates step (2) in Section 6.4.1. If no data dependence exists (i.e., predicate ${\sf DDep}$ is false ), the GPUs accumulated in ${{\text GpuOut}$_{p}$}$ are propagated to $n$. The presence of $\lnot {{\text ColIn}$_{p}$}$ in the equation for gpuFlow ensures that GPUs in GpuOut $_{p}$ are propagated to $\text{$\delta $} _{\text{n}}$ only if $\text{$\delta $} _{\text{n}}$ has not been found to be an $\mathit {entry}$ node of $\text{$\Pi $} (\text{$n$})$.

Fig. 13. The dataflow information computed by coalescing analysis for the example in Figure 12. The ColIn $_{}$ and ColOut $_{}$ values indicate that GPBs $\text{$\delta $} _1$, $\text{$\delta $} _2$, $\text{$\delta $} _3$, $\text{$\delta $} _4$, $\text{$\delta $} _5$ can be coalesced. Similarly, GPBs $\text{$\delta $} _6$ and $\text{$\delta $} _7$ can be coalesced. GPBs $\text{$\delta $} _5$ and $\text{$\delta $} _6$ must remain in different parts.

Example 32. Figure 13 gives the dataflow information for the example of Figure 12. GPBs $\text{$\delta $} _1$ and $\text{$\delta $} _2$ can be coalesced because ColOut $_{1}$ is true and GpuOut $_{1}$ is $\emptyset$. Thus, ${\sf DDep} (\text{$\delta $} _1, \text{$\delta $} _2)$ returns false ,indicating that types do not match, and hence there is no possibility of a data dependence between the GPUs of $\text{$\delta $} _1$ and $\text{$\delta $} _2$. Similarly, GPBs $\text{$\delta $} _1$ and $\text{$\delta $} _3$ can be coalesced. Thus, ColOut $_{1}$, ColIn $_{2}$, and ColIn $_{3}$ are true . We check the data dependence between the GPUs of GPBs $\text{$\delta $} _2$ and $\text{$\delta $} _4$ using the type information. However, ${\sf DDep} (\text{$\delta $} _2, \text{$\delta $} _4)$ returns false because the term $({{\text GpuOut}$_{2}$} - \text{$\delta $} _4)$ is $\emptyset$. Thus, GPBs $\text{$\delta $} _2$ and $\text{$\delta $} _4$ belong to the same part and can be coalesced. For GPBs $\text{$\delta $} _3$ and $\text{$\delta $} _4$, the possibility of data dependence is resolved based on the type information. The term $({{\text GpuOut}$_{3}$} - \text{$\delta $} _4)$ returns ${z}\mathop {\longrightarrow }\limits _{32}^{2|0}{o}$ whose ${\sf typeof} (z, 1)$ does not match that of the pointers being read in the GPUs in $\text{$\delta $} _4$. Thus, GPBs $\text{$\delta $} _3$ and $\text{$\delta $} _4$ can be coalesced. GPBs $\text{$\delta $} _4$ and $\text{$\delta $} _5$ both contain a GPU with a dereference; however, ${\sf DDep} (\text{$\delta $} _4, \text{$\delta $} _5)$ returns false ,indicating that there is no type matching, and hence no possibility of data dependence, thereby allowing the coalescing of the two GPBs. The ${\sf DDep} (\text{$\delta $} _5, \text{$\delta $} _6)$ returns true (type of source of the GPU ${x}\mathop {\longrightarrow }\limits _{12}^{2|0}{m} \in {{\text GpuOut}$_{5}$}$ matches the source of the GPU ${p}\mathop {\longrightarrow }\limits _{36}^{1|0}{s} \in \text{$\delta $} _6$), indicating a possibility of data dependence in the caller through aliasing, and hence the two GPBs cannot be coalesced. Thus, the first part is $\text{$\delta $} _8 = \left\lbrace \text{$\delta $} _1, \text{$\delta $} _2, \text{$\delta $} _3, \text{$\delta $} _4, \text{$\delta $} _5 \right\rbrace$. The loop $\text{$\delta $} _5 \rightarrow \text{$\delta $} _1$ before coalescing now reduces to the self-loop over GPB $\text{$\delta $} _8$ after coalescing and is eliminated. GPB $\text{$\delta $} _6$ becomes the entry of the new part. GPBs $\text{$\delta $} _6$ and $\text{$\delta $} _7$ can be coalesced as there is no data dependence between their GPUs. Note that the resulting partition is trivially coherent because each part is a single-entry and single-exit node.

GPU ${z}\mathop {\longrightarrow }\limits _{32}^{2|0}{o}$ has a definition-free path in $\text{$\delta $} _8$ because boundary definition ${z}\mathop {\longrightarrow }\limits _{0}^{2|2}{z}$ reaches the exit of part $\text{$\delta $} _8$ along the path $\text{$\delta $} _1 \rightarrow \text{$\delta $} _2 \rightarrow \text{$\delta $} _4 \rightarrow \text{$\delta $} _5$. No other GPU has a definition-free path.

Observe that some GPUs appear in multiple GPBs of a GPG (before coalescing). This is because we could have multiple calls to the same procedure. Thus, even though the GPBs are renumbered, the statement labels in the GPUs remain unchanged resulting in repetitive occurrence of a GPU. This is a design choice because it helps us accumulate the points-to information of a particular statement in all contexts.

Example 33. In Figure 4, GPBs $\text{$\delta $} _{01}$ and $\text{$\delta $} _{02}$ can be coalesced because ${\sf DDep} (\text{$\delta $} _{01}, \text{$\delta $} _{02})$ returns false ,indicating that there is no type matching and hence no possible data dependence between their GPUs. Thus, ColOut $_{01}$ and ColIn $_{02}$ are set to true . The loop formed by the back edge $\text{$\delta $} _{03} \rightarrow \text{$\delta $} _{01}$ reduces to a self-loop over GPB $\text{$\delta $} _{11}$ after coalescing. The self-loop is redundant, and hence it is eliminated. For GPBs $\text{$\delta $} _{02}$ and $\text{$\delta $} _{04}$, ${\sf DDep} (\text{$\delta $} _{02}, \text{$\delta $} _{04})$ returns true because ${\sf typeof} (q, 2)$ (for the GPU ${q}\mathop {\longrightarrow }\limits _{02}^{2|0}{m}$ in $\text{$\delta $} _{02}$) matches ${\sf typeof} (p, 2)$ (for the GPU ${e}\mathop {\longrightarrow }\limits _{04}^{1|2}{p}$ in $\text{$\delta $} _{04}$), which is $\tt int\, *$. This indicates the possibility of a data dependence between the GPUs of GPBs $\text{$\delta $} _{02}$ and $\text{$\delta $} _{04}$ ($q$ and $p$ could be aliased in the caller), and hence these GPBs cannot be coalesced. Thus, ColOut $_{02}$ and ColIn $_{04}$ are set to false . For GPBs $\text{$\delta $} _{04}$ and $\text{$\delta $} _5$, ${\sf DDep} (\text{$\delta $} _{04}, \text{$\delta $} _{05})$ returns false because there is no possible data dependence. Hence, ColOut $_{04}$ and ColIn $_{05}$ are set to true ,and the two GPBs can be coalesced.

Example 34. In Figure 4, $\text{$\mu $} _i = \emptyset$ for all nodes $i$ in the initial GPG. Strength reduction reduces the GPUs in $\text{$\delta $} _{02}$ and correspondingly updates $\text{$\mu $} _{02}$ to $\lbrace (b,1),(q,2)\rbrace$. After coalescing, the may-definition sets are computed to obtain $\text{$\mu $} _{11} = \lbrace (b,1),(q,2)\rbrace$ (because these sources have a definition-free path from the entry of $\text{$\delta $} _{01} \in \text{$\mathit {entry}$} (\text{$\delta $} _{11})$ to exit of $\text{$\delta $} _{02} \in \text{$\mathit {exit}$} (\text{$\delta $} _{11})$) and $\text{$\mu $} _{12} = \emptyset$.

For procedure $R$ (Figure 5), the boundary definition ${b}\mathop {\longrightarrow }\limits _{00}^{1|1}{b^{\prime }}$ reaches the exit of $\text{$\Delta $} _R,$ indicating that $b$ is may -defined. Hence, $\text{$\mu $} _{15} = \lbrace (b,1)\rbrace$. The GPU ${q}\mathop {\longrightarrow }\limits _{02}^{2|0}{m}$ reduces to ${d}\mathop {\longrightarrow }\limits _{02}^{1|0}{m}$ in $\text{$\delta $} _{13}$ in $\text{$\Delta $} _R$. Note that $d$ is defined in $\text{$\delta $} _{08}$ also, and hence neither $(q,2)$ nor $(d,1)$ is contained in $\text{$\mu $} _{15}$.

In this case, the GPG of the callee can be constructed completely before the GPG of its callers if we traverse the call graph bottom up.

We inline the optimized GPGs of the callees at the call sites in the caller procedures by renumbering the GPB nodes and each inlining of a callee gives fresh numbering to the nodes. This process does not change the statement labels within the GPUs. In addition, the upwards-exposed variable $x^{\prime }$ occurring in a callee's GPU inlined in the caller is substituted by the original variable $x$.

When inlining a callee's (optimized) GPG, we add two new GPBs, a predecessor to its Start $_{}$ GPB and a successor to its End $_{}$ GPB. These new GPBs respectively contain the following:

• GPUs that correspond to the actual-to-formal-parameter mapping.
  
• A GPU that maps the return variable of the callee to the receiver variable of the call in the caller (or zero GPUs for a void function).
  

Definition 10. Computing GPGs for recursive procedures by successive refinement.

Fig. 15. Series of GPGs of procedures $P$ and $Q$ of Figure 14. They are computed in the order shown in Figure 14(b). See Example 35 for an explanation.

Consider Figure 14, in which procedure $P$ calls procedure $Q$ and $Q$ calls $P$. The GPG of $Q$ depends on that of $P$ and vice versa, leading to incomplete GPGs: the GPGs of the callees of some calls either have not been constructed or are incomplete. We handle this mutual dependency by successive refinement of incomplete GPGs of $P$ and $Q,$ which involves inlining GPGs of the callee procedures, followed by GPG optimizations, repeatedly until a fixed point is reached. The rest of the section explains how refinement is performed and how a fixed point is defined and detected.

A set of recursive procedures is represented by a strongly connected component in a call graph. We construct GPGs for a set of recursive procedures by visiting the procedures in a post order obtained through a topological sort of the call graph. Because of recursion, the GPGs of some callees of the leaf are not available in the beginning. We handle such situations by using a special GPG $\text{$\Delta $} _{\top }$ that represents the effect of a call when the callee's GPG is not available. The GPG $\text{$\Delta $} _{\top }$ is the $\top$ element of the lattice of all possible procedure summaries. It kills all GPUs and generates none (thereby, when applied, it computes the $\top$ value—$\emptyset$—of the lattice for may -points-to analysis) [22]. This is consistent with using $\top$ value as the initialization for computing the maximum fixed-point solution in iterative dataflow analysis. Semantically, $\text{$\Delta $} _{\top }$ corresponds to the call to a procedure that never returns (e.g., loops forever). It consists of a special GPB called the call GPB whose flow functions are constant functions computing the empty set of GPUs for both variants of reaching GPUs analysis.

We perform the reaching GPUs analyses over incomplete GPGs containing recursive calls by repeated inlining of callees starting with $\text{$\Delta $} _{\top }$ as their initial GPGs, until no further inlining is required. Let $\text{$\Delta $} ^1_P$ denote the GPG of procedure $P$ in which all of the calls to the procedures that are not part of the strongly connected component are inlined by their respective optimized GPGs. Note that the GPGs of these procedures have already been constructed because of the bottom-up traversal over the call graph. The calls to procedures that are part of the strongly connected component are retained in $\text{$\Delta $} ^1_P$. In each step of refinement, the recursive calls in $\text{$\Delta $} ^1_P$ are inlined either by

• $\text{$\Delta $} _{\top }$ when no GPG of the callee has been constructed or
  
• an incomplete GPG of a callee in which some calls are underapproximated using $\text{$\Delta $} _{\top }$.
  

Thus, we compute a series of GPGs $\text{$\Delta $} ^i_P$, $i\gt 1$ for every procedure $P$ in a strongly connected component in the call graph until the termination of fixed-point computation. Once $\text{$\Delta $} ^i_P$ is constructed, we decide to construct $\text{$\Delta $} ^j_Q$ for a caller $Q$ of $P$ if the dataflow values of the End $_{}$ GPB of $\text{$\Delta $} ^{i}_P$ differ from those of the End $_{}$ GPB of $\text{$\Delta $} ^{i-1}_P$. This is because the overall effect of a procedure on its callers is reflected by the values reaching its End $_{}$ GPB (because of forward flow of information in points-to analysis). If the data values of the End $_{}$ GPBs of $\text{$\Delta $} ^{i-1}_P$ and $\text{$\Delta $} ^i_P$ are same, then they would have identical effect on their callers. Thus, the GPGs are semantically identical as procedure summaries even if they differ structurally. Thus, the convergence of this fixed-point computation differs subtly from the usual fixed-point computation in that it does not depend on matching the values at corresponding nodes (or the structure of the GPGs) across successive iterations. Instead, it depends on matching the dataflow values of the End $_{}$ GPB. This process is described in Definition 10.

We give an informal argument for termination of GPG construction in the presence of recursion. A formal and complete proof can be found in Gharat [10]. We first describe a property that holds for intraprocedural dataflow analysis over CFGs and then extend it to GPGs.

Consider a CFG $C_Q$ representing procedure $Q$ such that the flow functions associated with the nodes in $C_Q$ are monotonic and compute values in a finite lattice $L$. Let the dataflow value associated with the entry of Start $_{Q}$ and exit of End $_{Q}$ be denoted by In and Out ,respectively. We denote their relationship by writing ${\sf Out} = \text{$C_Q$} ({\sf In})$. Consider an arbitrary node $n$ in $C_Q$ whose flow function is $f_n$. Let $n$ be replaced by $n^{\prime }$ with flow function $f^{\prime }_n$ such that $f^{\prime }_n \sqsubseteq f_n$ (i.e., $\forall x \in L, f^{\prime }_n(x) \sqsubseteq f_n(x)$), giving us the CFG $C^{\prime }_Q$. Let ${\sf Out}^{\prime } = \text{$C^{\prime }_Q$} ({\sf In})$. We claim that ${\sf Out}^{\prime } \sqsubseteq {\sf Out}$. This follows from the fact that the control flow in $C_Q$ and $C^{\prime }_Q$ is the same, all flow functions are same except $f_n$ has been replaced by $f^{\prime }_n \sqsubseteq f_n$, and the same In value is supplied to both $C_Q$ and $C^{\prime }_Q$.

The preceding situation models call inlining in GPGs. From Section 3.1.3, the set of GPUs is finite, and from Gharat [10], they form a lattice with $\subseteq$ as the partial order. The flow function for a call GPB is initially assumed to be $f_\top ,$ and then the GPB is replaced by the GPG of the callee. The control flow surrounding this call remains same. Let the effect of the callee GPG be described by a flow function $f$. Clearly, $f \sqsubseteq f_\top$ because $f_\top$ computes $\top$ value. The process of successive refinements for handling recursion replaces call GPBs by the GPGs of the callees repeatedly. Consider a sequence of refinement, $ \text{$\Delta $} ^1_Q, \text{$\Delta $} ^2_Q, \ldots \text{$\Delta $} ^i_Q$. It can be proved by induction on the length of the sequence that the GPUs reaching the End $_{}$ GPB of the successive GPBs follow a descending chain because the boundary definitions at the Start $_{}$ GPB of every $\text{$\Delta $} ^i_Q$ are identical. Since the set of all possible GPUs is finite, this descending chain must contain two successive elements that are identical. Thus, there must exist $\text{$\Delta $} ^k_Q$ and $\text{$\Delta $} ^{k+1}_Q$ such that the GPUs reaching their End $_{}$ GPB are identical.

We model a call through function pointer (say fp) at call site $s$ as a use statement with a GPU (Section 8). Interleaving of strength reduction and call inlining reduces the GPU and provides the pointees of fp. This is identical to computing points-to information (Section 8). Until the pointees become available, the GPU acts as a barrier. Once the pointees become available, the indirect call converts to a set of direct calls (see Appendix C for an illustrative example). A naive approach to function pointer resolution would inline an indirect callee first into its immediate callers. This may require as many rounds of GPG construction as the maximum number of indirect calls in any call chain. Instead, we allow inlining directly in a transitive callee when a pointee of the function pointer of an indirect call becomes available. Hence, we can resolve all indirect calls in a call chain in a single round beginning with the indirect call closest to main. This is explained in Appendix C.

We do a whole-program analysis and assume that the entire source is available for analysis. Practically, there are very few library functions that influence the points-to relations of pointers to scalars in a C program. Library functions manipulating pointers into the heap can be manually represented by a GPB representing a sound overapproximation of their summaries.

For simplicity of reasoning, our proof does not talk about heap pointers. Our analysis computes a sound overapproximation of classical points-to analysis for heap pointers because (a) we use a simple allocation-site-based abstractions in which heap locations are not cloned context sensitively, and (b) we use $k$-limiting for heap pointers that are live on entry.

In the proof, we often talk about reaching GPUs analysis without making a distinction between reaching GPUs analysis with and without blocking. Blocking is discussed only in the proof of Lemma 9.11 because it is required to ensure soundness of GPU reduction.

Finally, our proofs use a simplistic model of programs where all variables are global and there is no parameter or return value mapping when making a call or when returning from a call. Including local variables, function parameters, and these mapping functions in the reasoning is a matter of detail and is not required for the spirit of the arguments made in the proof.

This section describes the top-down interprocedural flow- and context-sensitive points-to analysis. In keeping with the requirements of our proof of soundness (assumptions in Section 9.1), our formulation is restricted to global (non-structure) variables and direct procedure calls. Our formulation can be easily extended to support local variables, parameter mappings, return-value mappings, and structures; calls through function pointers can be handled using a standard approach of augmenting the call graph on the fly.

Our formulation is based on the classical Sharir-Pnueli tabulation method [34]. This method maintains pairs $(X,Y)$ of input-output dataflow values (hence the name tabulation method) for every procedure $Q$ where $X$ reaches Start $_{Q}$ and $Y$ is the corresponding value reaching End $_{Q}$ . The input value $X$ forms a context for context-sensitive analysis of $Q$. Every time a call to $Q$ is seen with the dataflow value $X$ reaching the call, the dataflow value $Y$ is used as the effect of the call. In other words, procedure $Q$ is reanalyzed only when a dataflow $X^{\prime }\ne X$ reaches a call to $Q$; the corresponding value $Y^{\prime }$ reaching End $_{Q}$ is then memoized as the pair $(X^{\prime },Y^{\prime })$.¹¹However, since the tabulation method is algorithmic, we use the ideas from value-contexts-based method [29] for a declarative description using dataflow equations.

The value-contexts-based method is subtly different the tabulation method in the following way. For each procedure $Q,$ this method creates a mapping represented as a set of pairs $(X,Y),$ with $X$ being a possible points-to graph reaching Start $_{Q}$ and and $Y$ being its associated points-to graph reaching End $_{Q}$ . During intraprocedural analysis, $X$ is held constant and represents the calling context, and $Y$, at each program point $n$ within $Q$, represents the points-to graph reaching $n$. This association of dataflow values at a program point with its context enables a declarative description of the method. Definition 11 provides the dataflow equations for may -points-to analysis using dataflow variables PTin $_{n}$/ PTout $_{n}$ for node $n$. The following two situations in the dataflow equations require special handling for maintaining context sensitivity:

• Context $X$ is generated at Start $_{Q}$ in the second case of the equation for PTin $_{n}$. Thus, the data flow value at Start $_{Q}$ is a set of pairs $(Y,Y)$.
  
• The context-sensitive data value after a call to some procedure $Q$ is computed by the first case in the equation for PTout $_{n}$. This is achieved by extracting the dataflow value (from PTout $_{{\sf End$_{Q}$}}$) that corresponds to the context in which the call to $Q$ was made.
  

Fig. 17. Different representations of the GPG of procedure $P$.

For other statements, the generated points-to information is the cross product of the pointers being defined by the statement (${{\sf Updated\_Ptrs}_{n}}$) and the locations whose addresses are read by the pointers on the RHS (${{\sf RHS\_Pointees}_{n}}$). The points-to information is killed by a statement when a strong update is possible (Section 2.1.3), which is the case for every direct assignment because the pointer in the LHS is overwritten (${{\sf Overwritten\_Ptrs}_{n}}$). For an indirect assignment, when the pointer appearing on the LHS has exactly one pointee and the pointer is not live on entry to main, the pointer is overwritten and the earlier pointees are removed. This is possible only when there is no definition-free path for the pointer from Start $_{\text{main}}$ to statement $n$. We eliminate such definition-free paths by making every pointer point to NULL at the Start $_{\text{main}}$ for its outermost call (the first case in PTin $_{n}$ equation); this is consistent with C semantics for global variables. This initialization may be adapted suitably to handle other static initializations in the program.

We need to name different versions of a GPG as it undergoes optimizations, analyses on these different versions, and GPBs of a callee inlined in a caller's GPG.

9.3.1 Naming the GPG Versions and Analyses. Recall that GPG construction creates a series of GPGs by progressively transforming them. For the purpose of proof, it is convenient to use notation that distinguishes between them. We use the notation in Figure 17 for different versions of a GPG. These different versions can have different possibilities of analyses that we show are equivalent using the following notation:

• TPT . Top-down flow- and context-sensitive classical points-to analysis (Section 9.2).
  
• TRG . Top-down flow- and context-sensitive reaching GPUs analysis.
  
• IRG . Intraprocedural reaching GPUs analysis.
  

Note that our implementation does not perform TPT or TRG .

Fig. 18. Constructing a GPG by call inlining.

Fig. 19. The overall organization of the soundness proof listing the lemmas that show equivalence of different analyses over different representations.

We use the classical points-to analysis defined in Section 9.2 as the gold standard and show that the GPG-based points-to analysis computes identical information (except when $k$-limiting is used for bounding indlist s for live-on-entry pointers to heap). Thus, our analysis is both sound and precise (for $k$-limited heap pointers, the precision can be controlled by choosing a suitable value of $k$).

Proof. Figure 19 illustrates the proof outline listing the lemmas that prove some key results. Since $\text{$\Delta $} _{P}^{\text{Init}}$ is constructed by simple transliteration (Section 3.3.1), we assume that it is a sound representation of the CFG of procedure $P$ with respect to classical flow- and context-sensitive points-to analysis. Then, using the points-to relations created by static initializations as memory $M$ (or set of GPUs) for boundary informationfor main,

Hence the theorem.

Recall that a top-down analysis uses the dataflow information reaching the call sites to compute the context-sensitive dataflow information within the callees. Thus, the information reaching the call sites is boundary information for an analysis of the callee procedures.

Lemma 9.4 argues about the GPUs that reach the GPBs for the statements in $P$ (and not the statements of the inlined callees), whereas Lemma 9.6 argues about the GPUs that reach the GPBs for the statements belonging to the (transitive) callees inlined in $\text{$\Delta $} _{P}^{\text{Call}}$.

In the following lemma, we need to consider the contexts of the calls within procedure $P$. For our reasoning, the way a context is defined does not matter, and we generically denote a context as $\sigma$. We assume that $\sigma$ denotes the full context without any approximation.

Lemma 9.8 (Claim C). Let $Q$ denote procedure $P$ or its transitive callees. Then, for a given boundary information (possibly containing points-to information and boundary definitions) for procedure $P$,

Recall that the abstract memory computed by a points-to analysis is a relation $\text{$M$} \subseteq {{\text L}$_{{\sf P}}$} \times {\sf L},$ where L denotes the set of locations and ${{\text L}$_{{\sf P}}$} \subseteq {\sf L}$ denotes the set of pointers. Given $M$, the direct pointees of a set of pointers $X\subseteq {{\text L}$_{{\sf P}}$}$ are computed by the relation application $\text{$M$} \; X = \lbrace y \mid (x,y) \in \text{$M$}, x\in X \rbrace$. Let $\text{$M$} ^i$ denote a composition of degree $i$. Then, $\text{$M$} ^i \lbrace x\rbrace$ discovers the $i^{th}$ pointees of $x,$ which involves $i$ transitive reads from $x\,$: first $i-1$ addresses are read followed by the content of the last address. By construction, $\text{$M$} ^0 \lbrace x\rbrace = \lbrace x \rbrace$. Abstract execution of GPU ${x}\stackrel{\rightarrow }{i|j}{y}$ in memory $M$ imposes the constraint $\text{$M$} ^i\lbrace x\rbrace \supseteq \text{$M$} ^j\lbrace y\rbrace$ on $M$ with weak updates; with strong updates, the constraint is stronger: $\text{$M$} ^i\lbrace x\rbrace = \text{$M$} ^j\lbrace y\rbrace$. Observe that $\text{$M$} ^i\lbrace x\rbrace \supseteq \text{$M$} ^j\lbrace y\rbrace \Rightarrow \text{$M$} ^{i+k}\lbrace x\rbrace \supseteq \text{$M$} ^{j+k}\lbrace y\rbrace$, $k\ge 0$; this also holds for equality (i.e., “$=$” instead of “$\supseteq$”).

Proof. Consider the picture on the right. The memory before the execution of is $M$ with no constraint, whereas the memory obtained after the execution of is $M$ with the constraint $C_p$. The mem-ory obtained after the execution of and is $M$ with the constraints $C_c\wedge C_p$ and $C_r\wedge C_p$, respectively. Then, the lemma can be proved by showing that $C_c\wedge C_p$ and $C_r\wedge C_p$ are identical. We first consider TS composition.

Initially, assume that causes a weak update; this assumption can be relaxed later. Let and be the GPUs illustrated in the first column of Figure 7. Since no other GPU with the source $(x,k^{\prime })$, $k^{\prime } \le k$, reaches , the constraint $C_p$ is $\text{$M$} ^k\lbrace x\rbrace = \text{$M$} ^l\lbrace y\rbrace$. The constraints $C_c$ is $\text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^j\lbrace x\rbrace$ and $C_r$ is $\text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^{(l+j-k)}\lbrace y\rbrace$.

\begin{align*} C_c \wedge C_p & = \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^j\lbrace x\rbrace \wedge \text{$M$} ^k\lbrace x\rbrace = \text{$M$} ^l\lbrace y\rbrace \\ & \Rightarrow \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^j\lbrace x\rbrace \wedge \text{$M$} ^{k+(j-k)}\lbrace x\rbrace = \text{$M$} ^{l+(j-k)}\lbrace y\rbrace \wedge \text{$M$} ^k\lbrace x\rbrace = \text{$M$} ^l\lbrace y\rbrace \;\;\; \text{(adding $j-k$ to $C_p$)} \\ & \Rightarrow \underbrace{ \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^j\lbrace x\rbrace \wedge \text{$M$} ^{j}\lbrace x\rbrace = \text{$M$} ^{l+(j-k)}\lbrace y\rbrace \,} \wedge \text{$M$} ^k\lbrace x\rbrace = \text{$M$} ^l\lbrace y\rbrace \\ & \Rightarrow \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^{l+j-k}\lbrace y\rbrace \wedge \text{$M$} ^k\lbrace x\rbrace \supseteq \text{$M$} ^l\lbrace y\rbrace \;\;\;\ \text{(combining the first two terms)} \\ & \Rightarrow C_r \wedge C_p \end{align*}

We also need to prove the implication in the reverse direction to show the equivalence.

\begin{align*} C_r \wedge C_p & = \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^{l+j-k}\lbrace y\rbrace \wedge \text{$M$} ^k\lbrace x\rbrace = \text{$M$} ^l\lbrace y\rbrace \\ & = \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^{l+j-k}\lbrace y\rbrace \wedge \text{$M$} ^l\lbrace y\rbrace = \text{$M$} ^k\lbrace x\rbrace \\ & \Rightarrow \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^{l+j-k}\lbrace y\rbrace \wedge \text{$M$} ^{l+(j-k)}\lbrace y\rbrace = \text{$M$} ^{k+(j-k)}\lbrace x\rbrace \wedge \text{$M$} ^k\lbrace x\rbrace = \text{$M$} ^l\lbrace y\rbrace \; \text{(adding $j-k$ to $C_p$)} \\ & \Rightarrow \underbrace{ \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^{l+j-k}\lbrace y\rbrace \wedge \text{$M$} ^{l+j-k}\lbrace y\rbrace = \text{$M$} ^{j}\lbrace x\rbrace } \wedge \text{$M$} ^k\lbrace x\rbrace = \text{$M$} ^l\lbrace y\rbrace \\ & \Rightarrow \text{$M$} ^i\lbrace z\rbrace \supseteq \text{$M$} ^{j}\lbrace x\rbrace \wedge \text{$M$} ^k\lbrace x\rbrace = \text{$M$} ^l\lbrace y\rbrace \;\;\;\ \text{(combining the first two terms)} \\ & \Rightarrow C_c \wedge C_p \end{align*}

This proves the lemma for TS composition when perform a weak update. When performs a strong update, the superset relation “$\supseteq$” is replaced by equality relation “$=,$”and it is easy to see that the two-way implication still holds. Similar arguments can be made for SS composition.

Lemma 9.12 shows the soundness of reaching GPUs analysis without blocking. The soundness of reaching GPUs analysis with blocking is shown in Lemma 9.13. Lemma 9.14 shows the precision of reaching GPUs analyses by arguing that every GPU that reaches a GPB is either generated by a GPB or is a boundary definition.

We implemented GPG-based points-to analysis in GCC 4.7.2 using the LTO framework and have carried out measurements on SPEC CPU2006 benchmarks on a machine with 16 GB of RAM with eight 64-bit Intel i7-7700 CPUs running at 4.20 GHz. The implementation can be downloaded from https://github.com/PritamMG/GPG-based-Points-to-Analysis.

This section describes the evaluations made on SPEC CPU 2006 benchmarks. The characteristics of benchmark programs in terms of number of procedures, number of pointer assignments, and the number of call sites is given in Table 1.

(We measured the data for the following two categories of evaluations:

• Comparing the precision of GPG-based FSCS points-to analysis and SVF-based points-to analysis (Section 10.2.1):
  
  • effect on mod-ref analysis and call graph construction, and
    
  • number of points-to pairs per procedure.
    
• Measuring the effectiveness of GPG-based FSCS points-to analysis (Section 10.2.2):
  
  • effectiveness of control flow optimizations,
    
  • quality of procedure summaries in terms of reusability, compactness (both absolute and relative), and
    
  • precision gain over FICS and FICI points-to analyses (in terms of number of points-to pairs per procedure). For our FSCS analysis, we compute this number by adding all points-to pairs computed as described in Section 8 across all procedures in a benchmark and then divide it by the number of procedures.