Scalable Context-Sensitive Points-to Analysis Using Multi-dimensional Bloom Filters

TL;DR: A scalable flow-insensitive context-sensitive inclusion-based points- to analysis that uses a specially designed multi-dimensional bloom filter to store the points-to information that achieves almost the same precision as the exact implementation.

Abstract: Context-sensitive points-to analysis is critical for several program optimizations. However, as the number of contexts grows exponentially, storage requirements for the analysis increase tremendously for large programs, making the analysis non-scalable. We propose a scalable flow-insensitive context-sensitive inclusion-based points-to analysis that uses a specially designed multi-dimensional bloom filter to store the points-to information. Two key observations motivate our proposal: (i ) points-to information (between pointer-object and between pointer-pointer) is sparse, and (ii ) moving from an exact to an approximate representation of points-to information only leads to reduced precision without affecting correctness of the (may-points-to) analysis. By using an approximate representation a multi-dimensional bloom filter can significantly reduce the memory requirements with a probabilistic bound on loss in precision. Experimental evaluation on SPEC 2000 benchmarks and two large open source programs reveals that with an average storage requirement of 4MB, our approach achieves almost the same precision (98.6%) as the exact implementation. By increasing the average memory to 27MB, it achieves precision upto 99.7% for these benchmarks. Using Mod/Ref analysis as the client, we find that the client analysis is not affected that often even when there is some loss of precision in the points-to representation. We find that the NoModRef percentage is within 2% of the exact analysis while requiring 4MB (maximum 15MB) memory and less than 4 minutes on average for the points-to analysis. Another major advantage of our technique is that it allows to trade off precision for memory usage of the analysis.

Summary

1 Introduction

• Pointer analysis enables many compiler optimization opportunities and remains as one of the most important compiler analyses.
• The objective of a context-sensitive points-to analysis is to construct, for each pointer and context, a set containing all the memory locations that the pointer can point to in that context.
• The third dimension (hash functions) is essential to control loss in precision.
• In effect, multibloom significantly reduces the memory requirement with a very low probabilistically bound loss in precision.
• The major contributions of this paper are: – We propose a multi-dimensional bloom filter that can compactly represent the points-to information with almost no loss in precision.the authors.the authors.

2 Background

• General purpose languages like C pose many challenges to the compiler community.
• Use of pointers hinders many compiler optimizations.
• Pointers with multiple indirections, pointers to functions, etc. only add to these challenges.
• The authors analysis handles all aspects of C (including recursion), except variable number of arguments.

2.1 Context-Sensitive Points-to Analysis

• A context-sensitive points-to analysis distinguishes between various calling contexts of a program and thus, is able to more accurately determine the points-to information compared to the context-insensitive version [5].
• The number of distinct paths from main to the leaf nodes in the graph is equal to the number of different contexts the program has.
• Therefore, for a context-sensitive points-to analysis, the number of points-to tuples can be exponential (in the number of functions in the program).
• Reducing the storage requirements of a context-sensitive points-to analysis has attracted much research in pointer analysis.
• Absolute values of memory and time required are substantially high.

2.2 Bloom Filter

• Note that element 3 also hashes to the same location as 13.
• This introduces false positives, as the membership query would return true for element 3 even if it is not inserted.
• The false positive rate can be reduced drastically by using multiple hash functions.
• P = (1/2)d (1 − nd N ) (1) This is under the assumption that the individual hash functions are random and different hash functions are independent.
• Unlike traditional data structures used in points-to analysis[5][8], time to insert elements in a bloom filter and to check for their membership is independent of the number of elements in the filter.

3 Points-to Analysis using Bloom Filters

• A naive implementation stores context-sensitive points-to tuples in a bloom filter by hashing the tuple 〈p, c, x〉 and setting that bit in the bloom filter.
• One way to solve this problem is to keep track of the set of all pointees .
• This way, the query FindPointsTo(p, c) to find the points-to set for a pointer p under context c is answered by checking the bits that are set for each of the pointees.
• It requires storing all possible pointees, making it storage inefficient.

3.1 Multi-Dimensional Bloom Filter

• The proposed multi-dimensional bloom filter is a generalization of the basic bloom filter introduced in Section 2.2.
• To obtain a good balance of storage requirement, analysis time and precision, the authors employ a combination of the above two techniques.
• The conservative strategy results in little precision loss considering that less than 1% of all dynamic pointer statements contain more than two levels of pointer indirections (obtained empirically).
• Extending multibloom for two-level pointers makes it look like mb[P ][S][C][D][B] where S is the number of entries for pointers that are pointees of a two-level pointer.
• Therefore the number of entries per bloom filter would be twice the average number of pointees per context-wise pointer.

4.1 Implementation Details and Experimental Setup

• All their implementation is done in the LLVM compiler infrastructure[13] and the analysis is run as a post linking phase.
• Neither version implements optimizations like offline variable substitution[16].
• Their characteristics are given in Table 1.
• The authors empirically found that the number of entries S for pointers pointed to by two-level pointers gives a good trade off between memory and precision for S = 5.
• From now on, when the authors report the results, they refer to the multibloom configuration by the tuple (C−D−B).

4.2 Tradeoff between Precision, Memory and Analysis Time

• In Tables 3-4 the authors report the precision, time and memory requirements for various benchmarks.
• At the other end, medium and large config- urations achieve full precision for all the benchmarks with significant savings in memory requirement for those requiring at least 15MB memory.
• For larger benchmarks the authors see significant improvements in analysis time using bloom filter.
• One unique advantage of using multibloom is the user-control over various parameters to trade off precision for memory or vice versa.
• The authors observe that with at most 1% reduction in average precision, they can obtain around 18% reduction in average memory requirement.

4.3 Mod/Ref Analysis as a Client to Points-to Analysis

• Next the authors analyze how the loss in precision in the points-to analysis due to false positives affect the client analyses.
• The authors use the Mod/Ref analysis as the client of their multibloom based points-to analysis.
• For a query GetModRef(callsite, pointer), the Mod/Ref analysis checks whether callsite reads or modifies the memory pointed to by pointer.
• From the figure, it can be seen that the NoModRef percentage with multibloom is 96.9% of the exact analysis even with a tiny configuration.
• For scalable analyses, one can reduce these values trading off some precision.

5 Related Work.

• Many scalable pointer analysis algorithms are context- and flow-insensitive [1].
• As scalability became an important factor with increasing code size, interesting mechanisms were introduced to approximate the precision of a full blown context-sensitive and flow-sensitive analysis. [17] proposed one level flow to improve precision of context-insensitive, flow-insensitive analyses, still maintaining the scalability.
• Since inclusion-based analyses are costly, several unificationbased algorithms were introduced, trading off precision for speed [1], [18].
• Several novel data structures have been used in the last decade to scale points-to analysis, like ROBDD[2][23][9], ZBDD[24].
• In contrast, bloom filters are useful for storing information in an approximate way.

6 Conclusions

• In this paper the authors propose the use of multi-dimensional bloom filter for storing points-to information.
• The proposed representation, though, may introduce false positives, significantly reduces the memory requirement and provides a probabilistic lower bound on loss of precision.
• With average 4MB memory, multibloom achieves almost the same (98.6%) precision as the exact analysis taking about average 4 minutes per benchmark.
• Using Mod/Ref analysis as the client, the authors find that the client analysis is not affected that often even with some loss of precision in points-to representation.
• The authors approach, for the first time, provides user a control on the memory requirement, yet giving a probabilistic lower bound on the loss in precision.

Figures

Table 1. Benchmark characteristics

Fig. 2. Example program to illustrate points-to analysis using bloom filters. First column shows the program statements. Later columns show the state of bloom filters for different pointers after successive iterations over constraints until a fix-point is reached.

Fig. 4. Mod/Ref client analysis.

Table 4. Precision (NoAlias %) vs Time (in sec). OOM means Out Of Memory. t is tiny, s is small, m is medium and l is large configuration.

Fig. 1. Example program and its invocation graph.

Table 3. Precision (NoAlias %) vs Memory (in KB). OOM means Out Of Memory.

Fig. 3. Example program to illustrate handling load/store statements. First column shows the program statements. Second column shows the bloom filter state after each statement is processed. Third column describes the multibloom operation.

Full text

Scalable Context-Sensitive Points-To Analysis
using Multi-Dimensional Bloom Filters.
Rupesh Nasre
1
, Kaushik Rajan
2
, R. Govindarajan
1
, Uday P. Khedker
3
.
1
Indian Institute of Science, Bangalore, India
2
Microsoft Research, Bangalore, India
3
Indian Institute of Technology, Bombay, India.
nasre@csa.iisc.ernet.in, kaushik@msr.microsoft.com,
govind@serc.iisc.ernet.in, uday@cse.iitb.ac.in
Abstract. Context-sensitive points-to analysis is critical for several pro-
gram optimizations. However, as the number of contexts grows exponen-
tially, storage requirements for the analysis increase tremendously for
large programs, making the analysis non-scalable. We propose a scal-
able flow-insensitive context -sensitive inclusion-based points-to analysis
that uses a specially designed multi-dimensional bloom filter to store
the points-to information. Two key observations motivate our proposal:
(i) points-to information (between pointer-object and between pointer-
pointer) is sparse, and (ii) movin g from an exact to an approximate
representation of points-to information only leads to reduced precision
without affecting correctness of the (may-points-to) analysis. By using
an approximate representation a multi-dimensional bloom filter can sig-
nificantly reduce the memory requirements with a probabilistic bound
on loss in precision. Experimental evaluation on SPEC 2000 benchmark s
and two large op en source programs reveals that with an average storage
requirement of 4MB, our approach achieves almost the same precision
(98.6%) as the exact implementation. By increasing the average mem-
ory to 27MB, it achieves p recision upto 99.7% for these benchmarks.
Using Mod/Ref analysis as the client, we find that the client analysis
is not affected that often even when there is some loss of precision in
the points-to representation. We fin d that the NoModRef percentage is
within 2% of the exact analysis while requiring 4MB (maximum 15MB)
memory and less than 4 minutes on average for the points-to analysis.
Another major advantage of our technique is that it allows to trade off
precision for memory usage of the analysis.
1 Introduction
Pointer analysis enables many compiler optimization opportunities and remains
as one of the most important compiler ana ly ses. For c lient analyses, both pre-
cision and speed of the underlying pointer analysis play a vital role. Several
context-insensitive algorithms have been shown to scale well for large programs
[1][2][3][4]. However, these algorithms are significantly less precise for rea l world

programs compared to their context-sensitive counterparts[5][6][7][8 ]. Unfortu-
nately, c ontext-sensitive pointer analysis improves precision at the cost of high —
often unacceptable — storage req uirement and analysis time. These large over-
heads ar e an artifact of the la rge number of contexts that a program might
have. For example, the SPEC2000 be nchmark eon has 19K pointers if we do not
consider context infor mation but the number increases to 417K pointers if we
consider all context-wise pointers. Scaling a context sensitive points-to analysis
is therefore a challenging task. Recent research (see Related Work in Section
5) has focused on the scalability aspect of context-sensitive points-to analysis
and achieves moderate success in that dir e ction[9][4]. However, the memory re-
quirements are still considerably large. For instance, in [9], most of the larger
benchmarks require over 100 MB for points-to analysis. Hence, scalability still
remains an issue. Also, none of the current analyses provide a handle to the user
to control the memo ry usage of a points-to analysis. Such a feature will be useful
when analyzing a progr am in a memor y constrained environment.
The objective of a context-sensitive points-to analysis is to construct, for
each pointer and context, a set containing all the memory locations (pointees)
that the pointer can point to in that context. This paper proposes a new way of
representing points-to information using a special kind of bloom filter[10] that
we call a multi-dimensional bloom filter.
A bloom filter is a compact, and approximate, representation (typically in
the form of bit vectors) of a set of elements which trades off some precision
for significa nt savings in memory. It is a lossy repre sentation that can incur
false positives, i.e., an element not in the set may be answered to be in the set.
However, it does not have false negatives, i.e., no element in the set would be
answered as not in the set. To mainta in this property, the operations on a bloom
filter are restricted so that items can only be added to the set but can never
be deleted
1
. Our motivation for using blo om filters for context-sensitive flow-
insensitive points to analysis stems from the following three key observations.
– Conservative static analysis: As with any other compiler analysis, static
points-to analysis tends to be conservative as correctness is an absolute re-
quirement. Thus, in c ase of sta tic may-points-to analysis, a pointer not point-
ing to a variable at run time can be considered otherwise, but not vice-versa.
As a bloom filter does not have fa lse negatives, a repr e sentation that uses
bloom filters is safe. A bloom filter can only (falsely) answer that a pointer
points to a few e xtra pointees. This only makes the analysis less precise and
does not po se any threat to c orrectness. Further, as a bloom filter is designed
to e fficiently trade off pr ecision for space it is an attractive representation to
enable sca lability of points-to analysis.
– Sparse points-to information: The number of pointees that each context-
wise pointer (pointer under a given context) actually points to is many or-
ders of magnitude less than both the number of context-wise pointers and
the total number of potential pointees. Hence, though the points-to set can
1
Some modified bloom filter structures[11] have been proposed that can support dele-
tion but they do so at the expense of introducing false negatives.

potentially be very large, in practice, it is typically small a nd sparse. A
bloom filter is idea lly suited to repr e sent data of this kind. When the set is
sparse, a bloom filter c an significantly reduce the memory requirement with
a probabilistically low bound o n loss in precision.
– Monotonic data flow analysis: As long as the underlying analysis uses
a monotonic iterative data flow analysis, the size of the points-to set can
only increase monotonically. This makes a bloom filter a suitable choice as
monotonicity guarantees that there is no need to support deletions.
The above observations make a bloom filter a promising candidate for represent-
ing points-to information. However, using the bloom filter as originally proposed
in [10] is not efficient for a context sensitive analysis. We therefore extend the
basic bloom filter to a multi-dimensional bloom filter (multibloom) to enable ef-
ficient storage and manipulation of context aware points-to information. The
added dimensions c orrespo nd to pointers, calling contexts, and hash functions.
The bloom filter is extended along the first two dimensions (pointers and calling
contexts) to support all the common pointer manipulation operations (p = q,
p = &q, p = ∗q and ∗p = q) and the query operation DoAlias(p, q) efficiently.
The third dimension (hash functions) is essential to control loss in precision. We
theoretically show and empirically observe that larger the number of hash func-
tions, lower is the loss in precision. In effect, multibloom significantly reduces
the memory requirement with a very low pro babilistically bound loss in pre-
cision. The compact representation of points-to information allows the context
sensitive analysis to scale well with the program size.
The major contributions of this pap er are:
– We propose a multi-dimensional blo om filter (multibloom) that can com-
pactly represent the points- to information with almost no loss in precision.
– Using extended bloom filter operations, we develop a contex t-s e nsitive flow-
insensitive points-to analysis for C programs in the LLVM compilation in-
frastructure.
– We show that by using multibloom, a user can control the total memory
requirement of a compiler analysis, unlike in most other analyses.
– We demonstrate the effectiveness of multibloom through experimenta l evalu-
ation on 16 SPEC 2000 benchmarks and 2 real world applications. With less
than 4MB memory on average (maximum 15MB ), multibloom achieves more
than 98% precision, taking les s than 4 minutes per benchmark on average.
– We also evaluate precision of a client Mod/ Ref analysis. We find that using
multibloom, the NoModRef percentage is within 1.3% of the exact analysis
while requiring 4MB memory and 4 minutes on average for the points-to
analysis.
2 Background
General purpose languages like C pose ma ny challenges to the compiler commu-
nity. Use of pointers hinders many compiler optimizations. Pointers w ith multiple

void main() {
S1: p1 = f(&x);
p3 = p1;
S2: p2 = f(&y);
}
int *f(int *a) {
S3: u = g(&x);
S4: v = g(&y);
return a;
}
int *g(int *b) {
return b;
}
int *u, *v;
g
f
main
ggg
f
S1 S2
S3 S4
S3 S4
Fig. 1. Example program and its invocation graph.
indirections, pointer s to functions, etc. only a dd to these challenges. For ana-
lyzing such complicated progr ams, however, it is sufficient to assume that all
pointer statements in the program are represented using one of the four basic
forms: address-of assignment (p = &q), copy assignment (p = q), load assignment
(p = ∗q) and store assig nment (∗p = q)[12] (we describe how these statements
are handled by our analysis in Section 3). Our analysis handles all aspects of C
(including re c ursion), except variable number of arguments.
2.1 Context-Sensitive Points-to Analysis
A context-sensitive points-to analysis distinguishes between various calling con-
texts of a program and thus, is able to more accurately determine the points-to
information compared to the context-insensitive version [5]. This pre cision, how-
ever, comes at a price: storing the number of contexts, which is huge in a large
C progr am. Consider the example progra m and its invocation gr aph shown in
Figure 1. The invocation graph shows that for different contexts, function f has
2 instances and function g has 4 instances. The number of distinct paths from
main to the leaf nodes in the graph is equal to the number of different con-
texts the program has. In general, the numb er of contexts in a prog ram can
be exponential in terms of the number of functions. For instance, the number
of methods in the open source program pmd is 197 1, but it has 10
23
context-
sensitive paths[9]. Therefore, for a context-sensitive points-to analysis, the num-
ber of points-to tuples can be exponential (in the number of functions in the
program). The exponential blow up in the number of contexts, typically results
in an exponential blow up in the storage requirement for exact representation of
context-wise po ints-to tuples.
Reducing the storage requirements of a context-sensitive points- to analysis
has attracted much research in pointer analysis. Several novel approaches have
been proposed for scalable pointer analyses (see Section 5 for r e lated work).
Despite these advances, absolute values of memory and time required are sub-
stantially high. For instance, in [9], all the benchmarks having more than 10K
methods (columba, gantt, jxplorer, jedit, gruntspud) require over 100MB of mem-
ory. For the benchmarks we evaluate, we find that the number of pointers in-
creases by 1 or 2 orders of magnitude if we track them in a context-wise manner.
So it is po ssible that the memory and time requirements of a context-sensitive

analysis will be a few orders of ma gnitude higher than a context insensitive
analysis.
Our goal, in this paper, is to reduce this storage and e xecution time require-
ment of a context-sensitive points-to analysis. This is achieved by using a variant
of bloom filter, which sacrifices a small amount of precision. As we shall se e in
the next subsection, once the user fixes the size of a bloom filter, he/she can es-
timate a probabilistic bound on the loss in precision as a function of the average
number of pointees of a pointer (in a given context).
2.2 Bloom Filter
A bloom filter is a probabilistic data structure used to store a set of elements
and test the membership of a given element[10]. In its simplest form, a bloom
filter is an array of N bits. An element e belonging to the set is represented
by setting the kth bit to 1, where h(e) = k and h is the hash function mapping
element e to k
th
bit. For instance, if the hash function is h
1
(e) = (3 ∗ e+ 5)%N,
and if N = 10, then for elements e = 13 and 100, the bits 4 and 5 are set.
Membership of an element e is tested by using the same hash function. Note
that element 3 also hashes to the same location as 13. This intr oduces false
positives, as the membership query would retur n true fo r element 3 even if it is
not inse rted. Note, however, that there is no possibility of false negatives, since
we never reset any bit.
The false positive rate can be reduced drastically by using multiple hash
functions. Thus, if we use two hash functions for the above example, with
h
2
(e) = (⌊e/2⌋ + 9)%N , then the elements e = 13, 100 get hashed to bits
5, 9. No te that a membership query to 3 would return false as location 0 (cor-
responding to h
2
(3)) is 0, even though location 4 (corresponding to h
1
(3)) is set.
Thus, us ing multiple hash functions the false positives can be reduced.
The fals e positive rate P fo r a bloom filter of size N bits after n elements are
added to the filter with d hash functions is given by Equation 1 (from [10]).
P =
(1/2)
d
(1 −
nd
N
)
(1)
This is under the assumption that the individual hash functions are random and
different hash functions are independent. Unlike traditional data structures used
in points-to analy sis[5][8], time to insert elements in a bloom filter and to check
for their membership is independent of the number of elements in the filter.
3 Points-to Analysis using Bloom Filters
A points-to tuple hp, c, xi represents a pointer p pointing to variable x in calling
context c. A context is defined by a sequence of functions and their call-sites. A
naive implementation stores context-sensitive points-to tuples in a bloom filter
by hashing the tuple hp, c, xi and setting that bit in the bloom filter. This simple

Frequently asked questions

Q1. What contributions have the authors mentioned in the paper "Scalable context-sensitive points-to analysis using multi-dimensional bloom filters" ?

The authors propose a scalable flow-insensitive context-sensitive inclusion-based points-to analysis that uses a specially designed multi-dimensional bloom filter to store the points-to information. Experimental evaluation on SPEC 2000 benchmarks and two large open source programs reveals that with an average storage requirement of 4MB, their approach achieves almost the same precision ( 98. 6 % ) as the exact implementation. Using Mod/Ref analysis as the client, the authors find that the client analysis is not affected that often even when there is some loss of precision in the points-to representation. 

Q2. What have the authors stated for future works in "Scalable context-sensitive points-to analysis using multi-dimensional bloom filters" ?

As a future work, it would be interesting to see the effect of approximation introduced using bloom filters with the approximations introduced in control-flow analyses such as kCFA or in unification of contexts. 

Q3. What is the important aspect of pointer analysis?

context-sensitive pointer analysis improves precision at the cost of high — often unacceptable — storage requirement and analysis time. 

Q4. What is the common query that is used for a point-to analysis?

For a query GetModRef(callsite, pointer), the Mod/Ref analysis checks whether callsite reads or modifies the memory pointed to by pointer. 

Q5. What is the way to handle load statement?

To handle load statement p = ∗q where p is a single-level pointer and q is a two-level pointer, all the cubes mb[Q][i] (i.e., C × D × B bits) corresponding to pointer q, ∀i = 1..S are bitwise-ORed to get a resultant cube. 

Q6. What is the meaning of a point-to-tuple?

A points-to tuple 〈p, c, x〉 represents a pointer p pointing to variable x in calling context c. A context is defined by a sequence of functions and their call-sites. 

Q7. How does a naive implementation store tuples in a bloom filter?

A naive implementation stores context-sensitive points-to tuples in a bloom filter by hashing the tuple 〈p, c, x〉 and setting that bit in the bloom filter. 

Q8. How many benchmarks run out of memory when the authors run an exact analysis?

Three out of the 18 benchmarks run out of memory when the authors run an exact analysis, highlighting the need for a scalable context-sensitive points-to analysis. 

Q9. What enhancements have been made to the original Andersen’s inclusionbased algorithm?

Various enhancements have also been made to the original Andersen’s inclusionbased algorithm: online cycle elimination[20] to break dependence cycles on the fly, offline variable substitution[16] to reduce the number of pointers tracked during the analysis, location equivalence[21] and semi-sparse flow-sensitivity[22]. 

Q10. How many times does a multibloom fail to map the values?

To measure the false positive rate the authors will now try to map the values back from a 4-dimensional multibloom to a 2-dimensional bloom filter so that the authors can apply Equation 1. 

Q11. How is the scalability of multibloom improved?

As scalability became an important factor with increasing code size, interesting mechanisms were introduced to approximate the precision of a full blowncontext-sensitive and flow-sensitive analysis. [17] proposed one level flow to improve precision of context-insensitive, flow-insensitive analyses, still maintaining the scalability. 

Q12. What is the mapping function for hs?

4. The mapping function hs is defined as hs(p1) = 1 and hs(p2) = 2. Initially, all bits in the buckets for each pointer are set to 0. 

Q13. What is the number of lines of code in a spec 2000 benchmark?

KLOC is the number of Kilo lines of code, Total Inst is the total number of static LLVM instructions, Pointer Inst is the number of static pointer-type LLVM instructions and No. of Fns is the number of functions in the benchmark. 

Q14. What is the simplest way to handle a load statement?

It makes each pointer pointed to by q point to the pointees pointed to by p.Handling context-sensitive load/store statements requires a modification to address-of assignment p = &q. 

Q15. How much memory is required for all benchmarks?

The memory requirement is three orders less, while the access time is reduced to about one-fourth for all benchmarks which take at least 20 seconds. 

Q16. How many bits does the algorithm need to map to a given context?

For each hash function the algorithm needs to determine if the corresponding bit vectors have at least one common bit with the value 1. 

Q17. How much precision can a client analysis enjoy?

This shows that a client analysis is hardly affected due to loss in precision by using an approximate representation, while still enjoying the benefits of reduced memory and time requirements. 

Q18. What is the false positive rate for a bloom filter?

The false positive rate P for a bloom filter of size N bits after n elements are added to the filter with d hash functions is given by Equation 1 (from [10]).