Transcript clweb.csa.iisc.ernet.in

Scalable Points-to Analysis.
Rupesh Nasre.
Advisor: Prof. R. Govindarajan.
Comprehensive Examination.
Jun 22, 2009.
Outline.

Introduction (points-to analysis).

Issues involved in context-sensitive analyses.

Bloom filter.

Points-to analysis with bloom filter.

Experimental evaluation.

Future work.
What is Pointer Analysis?
Pointer analysis is the mechanism of statically
finding out possible run-time values of a pointer
and
relation of various pointers with each other.
Why Pointer Analysis?

for parallelization:
fun(p);
fun(q);

for common subexpression elimination:
x = p + 2;
y = q + 2;

for dead code elimination.
if (p == q) {
fun();
}

for other optimizations.
Introduction.

Flow sensitivity.

Context sensitivity.

Field sensitivity.

Unification based.

Inclusion based.
Flow sensitivity.
p = &x;
p = &y;
label:
...
flow-sensitive, at label: {(p, y)}.
flow-insensitive: {(p, x), (p, y)}.
Context sensitivity.
caller1() {
caller2() {
fun(&x);
}
fun(int *ptr) {
fun(&y);
}
a = ptr;
}
context-insensitive: {(a, x), (a, y)}.
context-sensitive: {(a, x)} along call-path caller1,
{(a, y)} along call-path caller2.
Field sensitivity.
a.f = &x;
field-sensitive: {(a.f, x)}.
field-insensitive: {(a, x)}.
Unification based.
one(&s1);
one(struct s*p) {
one(&s2);
p->a = 3;
two(&s3);
two(p);
two(struct s*q) {
q->b = 4;
}
}
unification-based: {(p, &s1), (p, &s2), (p, &s3),
(q, &s1), (q, &s2), (q, &s3)}.
Inclusion based.
one(&s1);
one(struct s*p) {
one(&s2);
p->a = 3;
two(&s3);
two(p);
two(struct s*q) {
q->b = 4;
}
}
inclusion-based: {(p, &s1), (p, &s2),
(q, &s1), (q, &s2), (q, &s3)}
Related work.
Scalable points-to analyses.




B. Steensgaard, Points-to Analysis in Almost Linear Time, POPL
1996.
J. Whaley and M. S. Lam, Cloning-Based Context-Sensitive Pointer
Alias Analysis Using Binary Decision Diagrams, PLDI 2004.
B. Hardekopf and C. Lin, The ant and the grasshopper: fast and
accurate pointer analysis for millions of lines of code, PLDI 2007.
V. Kahlon, Bootstrapping: a technique for scalable flow and contextsensitive pointer alias analysis, PLDI 2008.
Issues with context-sensitivity.
main() {
f(a) {
g(b) {
S1: f(&x);
S3: g(a);
...
S2: f(&y);
S4: g(z);
...
}
}
}
main
S2
S1
f
S3
g
f
S4
S3
S4
g
g
g
Invocation graph.
Exponential
number of
contexts.
Issues with context-sensitivity.
Storage requirement increases exponentially.
Along S1-S3-S5-S7, p points to {x1, x3, x5, x7}.
Along S1-S3-S5-S8, p points to {x1, x3, x5, x8}.
Along S1-S3-S6-S7, p points to {x1, x3, x6, x7}.
Along S1-S3-S6-S8, p points to {x1, x3, x6, x8}.
Along S1-S4-S5-S7, p points to {x1, x4, x5, x7}.
Along S1-S4-S5-S8, p points to {x1, x4, x5, x8}.
Along S1-S4-S6-S7, p points to {x1, x4, x6, x7}.
Along S1-S4-S6-S8, p points to {x1, x4, x6, x8}.
Along S2...
Tackling scalability issues.
How about not storing complete contexts?
How about storing approximate points-to information?
Can we have a probabilistic data structure that approximates
the storage?
Can we control the false-positive rate?
Bloom filter.
A bloom filter is a probabilistic data structure for
membership queries, and is typically implemented as a
fixed-sized array of bits.
To store elements e1, e2, e3, bits at positions hash(e1),
hash(e2) and hash(e3) are set.
1
1
e1, e3
e2
Points-to analysis with Bloom filter.
A constraint is an abstract representation of the
pointer instruction.

p = &x
p.pointsTo(x).

p=q
p.copyFrom(q).

*p = q
p.storeThrough(q).

p = *q
p.loadFrom(q).
Function arguments and return values resemble
p = q type of statement.
Note, each constraint also stores the context.
Points-to Analysis with Bloom filter.
If points-to pairs (p, x) are kept in bloom filter,
existential queries like “does p point to x?” can be
answered.
What about queries like “do p and q alias?”?
What about context-sensitive queries like “do p and q
alias in context c?”?
How to process assignment statements p = q?
How about load/store statements *p = q and q = *p?
Multi-Bloom filter.
Points-to pairs are kept in a bloom filter per pointer. A
bit set to 1 represents a points-to pair.
Example (diagram on the next slide):
Points-to pairs {(p, x), (p, y), (q, x)}.
hash(x) = 5, hash(y) = 6.
Set bit numbers: p.bucket[5], p.bucket[6], q.bucket[5].
Can hash(x) and hash(y) be the same? Yes.
Multi-Bloom filter.
p.bucket
.0
0 0 0 0
0
5 6
1 1 0
(p, x)
0
0
0
0
(p,y)
q.bucket
.0
5
0 0 0 0 0 1 0
(q, x)
Multi-Bloom filter.
Each pointer has a fixed number of bits for
storing its points-to information, called as a
bucket.
Thus, if bucket size == 10, all pointees are hashed to a value
from 0 to 9.
This notion is extended to have multiple buckets for each pointer
for multiple hash functions.
Handling p = q.


Points-to set of q should be added to the pointsto set of p.
Bitwise-OR each bucket of q with the
corresponding bucket of p.
Example on the next slide.
Example.

h1(x) = 0, h2(x) = 5, h1(y) = 3, h2(y) = 3.
Handling p = *q and *p = q.



Extend multi-bloom to have another dimension
for pointers pointed to by pointers.
The idea can be extended to higher-level
pointers (***p, ****p, and so on).
We implemented it only for two-level pointers.
Example on the next slide.
Another example.

h(x) = 1, h(y) = 4, hs(p1) = 1, hs(p2) = 2.
Alias query: context-sensitive.
If the query is DoAlias(p, q, c),
for each hash function ii {
hasPointee = false;
for each bucket-bit jj
if (p.bucket[c][ii][jj] and q.bucket[c][ii][jj])
hasPointee = true;
if (hasPointee == false)
return NoAlias;
}
return MayAlias;
Alias query: context-insensitive.
If the query is DoAlias(p, q),
for each context c {
if (DoAlias(p, q, c) == MayAlias)
return MayAlias;
}
return NoAlias;
Experimental evaluation: Time.
gcc
perlbmk
vortex
eon
parser
gap
vpr
crafty
mesa
ammp
twolf
gzip
bzip2
mcf
equake
art
httpd
sendmail
exact.
OOM.
OOM.
OOM.
231.166
55.359
144.181
29.702
20.469
1.472
1.120
0.596
0.348
0.148
0.112
0.224
0.168
17.445
5.956
(40-10-4)
791.705
76.277
95.934
39.138
9.469
5.444
5.104
2.636
1.384
1.008
0.656
0.192
0.144
0.332
0.104
0.164
7.180
3.772
(80-10-8)
3250.627
235.207
296.995
118.947
31.166
17.469
18.085
9.069
2.632
2.592
1.152
0.372
0.284
0.820
0.236
0.408
15.277
6.272
(400-100-12)
10237.702
2632.044
1998.501
1241.602
145.777
152.102
88.826
46.899
10.041
15.185
5.132
1.808
1.348
5.036
1.104
2.404
52.793
25.346
(800-100-16)
27291.303
5429.385
4950.321
2639.796
353.382
419.392
211.065
109.115
23.721
38.018
12.433
4.372
3.288
12.677
2.652
6.132
127.503
65.889
Experimental evaluation: Memory.
gcc
perlbmk
vortex
eon
parser
gap
vpr
crafty
mesa
ammp
twolf
gzip
bzip2
mcf
equake
art
httpd
sendmail
exact.
OOM.
OOM.
OOM.
385283.89
121587.5
97862.67
50209.5
15985.59
8260.22
5843.27
1593.69
1446.47
518.88
219.57
160.13
41.46
225512.89
197382.28
(40-10-4)
3955.39
1880.87
817.89
1722.32
564.19
1106.97
309.98
142.59
720.95
200.09
440.73
41.96
30.56
49.20
52.00
22.18
3058.17
1672.88
(80-10-8)
15444.90
7344.33
3193.65
6725.23
2203.01
4322.47
1210.40
556.78
2815.14
781.30
1720.93
163.84
119.31
192.13
203.03
86.59
11941.40
6532.20
(400-100-12)
113576.00
54007.70
23485.00
49455.00
16200.20
31785.90
8900.88
4094.37
20701.60
5745.38
12655.20
1204.79
877.37
1412.83
1493.03
636.77
87813.10
48035.60
(800-100-16)
302117.00
143662.00
62471.00
131552.00
43093.10
84551.70
23676.60
10891.20
55066.90
15282.90
33663.10
3204.79
2333.82
3758.17
3971.50
1693.82
233586.00
127776.00
Experimental evaluation: Precision.
gcc
perlbmk
vortex
eon
parser
gap
vpr
crafty
mesa
ammp
twolf
gzip
bzip2
mcf
equake
art
httpd
sendmail
exact.
OOM
OOM
OOM
96.8
98.0
97.5
94.2
97.6
99.4
99.2
99.3
90.9
88.0
94.5
97.7
88.6
93.2
90.4
(40-10-4)
71.8
75.3
85.7
81.5
65.8
88.2
85.9
97.1
89.6
98.4
96.7
88.8
84.8
91.3
96.9
86.6
90.1
85.6
(80-10-8)
79.6
85.0
90.1
88.9
97.3
93.5
93.9
97.6
96.6
99.0
99.1
90.5
88.0
94.3
97.7
88.4
92.1
88.2
(400-100-12)
83.4
89.3
91.2
94.3
97.9
96.7
94.1
97.6
99.1
99.2
99.3
90.8
88.0
94.5
97.7
88.6
92.9
90.3
(800-100-16)
85.3
90.6
91.5
96.8
98.0
97.4
94.2
97.6
99.4
99.2
99.3
90.9
88.0
94.5
97.7
88.6
93.2
90.4
Summary.

Bloom filters offer an effective way to represent points-to
information.

Precision can be as close to exact, still saving storage.

Parameters can be configured for an application usage.
Future work.

Flow-sensitive analysis using counting bloom filter.

need to support kill operation.

require resetting bits.

may introduce false negatives.

storage requirement of flow-sensitive analysis is an
issue.
Future work.

Adaptive bloom filter parameters.

not all pointers require same number of bits.

bits saved from one pointer can be used by another.

storage required for counters representing number of
bits for each pointer.

bitwise operations are not straightforward.
Future work.

Efficient flow-insensitive analysis.

approach similar to wave/deep propagation¹.

similarity with flow-sensitive analysis.

preliminary results show that the number of iterations to
reach a fix-point can be reduced, e.g., on an example
set of programs, total number of iterations are reduced
from 180 (deep) to 148.
¹ F M Q Periera, Daniel Berlin, Wave Propagation and Deep Propagation for Pointer Analysis, CGO 2009.
Scalable Points-to Analysis.
Rupesh Nasre.
Advisor: Prof. R. Govindarajan.
Comprehensive Examination.
Jun 22, 2009.
Approach.

Start from main().

Add constraints for each pointer statement.

Flow-insensitive.




Jump to the called function, process it and return. Continue
with the caller. A function called multiple times is processed
multiple times.
Keep context along with each constraint.
Recursion is handled by iterating over the cycle until a fixpoint. This is context-insensitive.
At the end, iterate over constraints to extract points-to
information in context-sensitive manner. Iteration makes it
flow-insensitive.
Example.
main() {
f(a) {
S1:r1 = f(p)
return a
S2:r2 = f(q)
}
S3:r3 = g(p) g(b) {
S4:r4 = h()
}
c=b
}
h() {
p = &x
q = &y
}
Only realizable
paths.
Along main-S1, r1
points to x.
Along main-S2, r2
points to y.
Even though main-S3 and mainS4 are
different contexts, we merge
context-information. Thus, c
points to x.
Since main-S1 and main-S2 call the
same function, we do not merge the
information. Thus, r1 does not alias
with r2.
Experimental evaluation: Mod/Ref.
gcc
perlbmk
vortex
eon
parser
gap
vpr
crafty
mesa
ammp
twolf
gzip
bzip2
mcf
equake
art
httpd
sendmail
exact.
OOM
OOM
OOM
41.2
29.9
51.1
73.5
93.4
25.6
57.9
69.1
30
44.7
51.3
95.2
64.8
52.9
43.3
(40-10-4)
19.5
16.3
25.9
38.1
26.7
48.4
71.4
93.2
22.9
56.3
67.3
29.8
44.5
50.8
93.7
64.4
50.6
40.8
(80-10-8)
24.6
24.7
35.7
39.8
28.3
49.8
72.9
93.4
24.3
57.5
68.6
29.9
44.7
51.3
94.9
64.7
51.8
42
(400-100-12)
28.9
28
38.4
40.9
28.8
50.7
73.4
93.4
25.2
57.8
68.9
30
44.7
51.3
95.2
64.8
52.8
43.1
(800-100-16)
29.5
29.1
39.1
41.2
28.9
51
73.5
93.4
25.6
57.9
69.1
30
44.7
51.3
95.2
64.8
52.9
43.3