Dfa Motivation Handout

Introduction to Program Analysis
Uday Khedker
(www.cse.iitb.ac.in/uday)
Part 1
Department of Computer Science and Engineering,
About These Slides
Indian Institute of Technology, Bombay
July 2015
CS 618
1/57
Intro to PA: About These Slides
CS 618
2/57
Intro to PA: Outline
Copyright
Motivating the Need of Program Analysis
These slides constitute the lecture notes for CS618 Program Analysis course at
IIT Bombay and have been made available as teaching material accompanying
the book:
Uday Khedker, Amitabha Sanyal, and Bageshri Karkare.
Data Flow Analysis: Theory and Practice. CRC Press (Taylor and Francis
Group). 2009.
(Indian edition published by Ane Books in 2013)
Apart from the above book, some slides are based on the material from the
following books
A. V. Aho, M. Lam, R. Sethi, and J. D. Ullman. Compilers: Principles,
Techniques, and Tools. Addison-Wesley. 2006.
M. S. Hecht. Flow Analysis of Computer Programs. Elsevier
North-Holland Inc. 1977.
Some representative examples
Classical optimizations performed by compilers

Optimizing heap memory usage
Course details, schedule, assessment policies etc.

Soundness and Precision
Program Model
These slides are being made available under GNU FDL v1.2 or later purely for
academic or research use.
July 2015
IIT Bombay
July 2015
IIT Bombay
Intro to PA: Classical Optimizations
CS 618
3/57
Examples of Optimising Transformations (ALSU, 2006)

A C program and its optimizations
void quicksort(int m, int n)
{ int i, j, v, x;
if (n <= m) return;
i = m-1; j = n; v = a[n];
while(1)
{ do i = i + 1; while (a[i] < v);
do j = j - 1; while (a[j] > v);
if (i >= j) break;
x = a[i]; a[i] = a[j]; a[j] = x;
}
x = a[i]; a[i] = a[n]; a[n] = x;
quicksort(m,i); quicksort(i+1,n);
}
/ the left of sp and to the
Part 2
Classical Optimizations
/ v is the pivot
/ Move values smaller
/ than v to the left of
/ the split point (sp)
/ and other values
/ to the right of sp
/ of the split point
/ Move the pivot to sp
/ sort the partitions to
right of sp independently
July 2015
CS 618
4/57
/
/
/
/
/
/
/
/
/
/
IIT Bombay
CS 618
Intermediate Code
5/57
Intermediate Code : Observations
For the boxed source code

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
July 2015
i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
i=i+1
t2 = 4 i
t3 = a[t2]
if t3 < v goto 6
j=j-1
t4 = 4 j
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
t5 = a[t4]
if t5 > v goto 10
if i >= j goto 25
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
a[t4] = x
goto 6
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = x
IIT Bombay
Multiple computations of expressions

Simple control flow (conditional/unconditional goto)
Yet undecipherable!
Array address calculations
July 2015
IIT Bombay
CS 618
6/57
CS 618
Understanding Control Flow
Intermediate Code with Basic Blocks
1.
2.
3.
4.
5.
6.
7.
8.
9.
Identify maximal sequences of linear control flow

Basic Blocks
No transfer into or out of basic blocks except the first and last statements
Control transfer into the block : only at the first statement.
Control transfer out of the block : only at the last statement.
i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
i=i+1
t2 = 4 i
t3 = a[t2]
if t3 < v goto 6
IIT Bombay
CS 618
B1
B6
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = x
July 2015
B1
B2
14. if i >= j goto 25
25.
26.
27.
28.
29.
30.
31.
32.
33.
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = x
8/57
CS 618
IIT Bombay
9/57
Program Flow Graph : Observations
i=i+1
t2 = 4 i
B2
t3 = a[t2]
if t3 < v goto B2
B3
j=j-1
t4 = 4 j
B3
t5 = a[t4]
B5
if t5 > v goto B3
B4
if i >= j goto B6 B4
B6
23. a[t4] = x
24. goto 6
July 2015
Program Flow Graph

i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
12. t5 = a[t4]
13. if t5 > v goto 10
15.
16.
17.
18.
19.
20.
21.
22.
10. j = j - 1
11. t4 = 4 j
July 2015
7/57
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
a[t4] = x
goto B2
IIT Bombay
Nesting Level
0
1
2
B5
July 2015
Basic Blocks
B1, B6
B4, B5
B2, B3
No. of Statements
14
11
8
IIT Bombay
CS 618
10/57
CS 618
Local Common Subexpression Elimination
B1
B6
i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
B1
B2
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = x
B3
B6
B4
Global Common Subexpression Elimination
i=i+1
t2 = 4 i
B2
t3 = a[t2]
if t3 < v goto B2
B1
j=j-1
t4 = 4 j
B3
t5 = a[t4]
B5
if t5 > v goto B3
July 2015
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
a[t4] = x
goto B2
B5
B6
IIT Bombay
CS 618
i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
x = t3
t2 = 4 i
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = x
12/57
B6
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = x
B1
B2
B3
B6
B4
i=i+1
t2 = 4 i
B2
t3 = a[t2]
if t3 < v goto B2
j=j-1
t4 = 4 j
B3
t5 = a[t4]
B5
if t5 > v goto B3
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
a[t4] = x
goto B2
B2
i =i +1
t2 = 4 i
B2
i =i +1
t2 = 4 i
B2
i =i +1
t2 = 4 i
B2
i =i +1
t2 = 4 i
...
July 2015
B1
B6
B4
B5
B4
x = t3
t2 = 4 i
a[t2] = t5
t4 = 4 j
a[t4] = x
goto B2
B5
IIT Bombay
13/57
B3
B5
B3
j=j-1
t4 = 4 j
B3
t5 = a[t4]
B5
if t5 > v goto B3
B6
CS 618
...
i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
B2
i=i+1
t2 = 4 i
B2
t3 = a[t2]
if t3 < v goto B2
B1
July 2015
B1
11/57
t2 = 4 i
IIT Bombay
i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = x
July 2015
B1
B2
i=i+1
t2 = 4 i
B2
t3 = a[t2]
if t3 < v goto B2
B3
j=j-1
t4 = 4 j
B3
t5 = a[t4]
B5
if t5 > v goto B3
B4
B6
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
a[t4] = x
goto B2
IIT Bombay
B5
CS 618
14/57
CS 618
Other Classical Optimizations
Copy Propagation and Dead Code Elimination
B1
i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
B1
B2
Copy propagation
Strength Reduction
Elimination of Induction Variables
Dead Code Elimination
B6
July 2015
IIT Bombay
CS 618
B1
B6
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = t3
July 2015
B1
B2
16/57
B3
B6
B4
j=j-1
t4 = t4 4
B3
t5 = a[t4]
B5
if t5 > v goto B3
if t2>=t4 goto B6 B4
IIT Bombay
B3
j=j-1
t4 = 4 j
B3
t5 = a[t4]
B5
if t5 > v goto B3
B4
B6
B5
B6
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
a[t4] = t3
goto B2
i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
t2 = 4 i
t4 = 4 j
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = t3
July 2015
B5
IIT Bombay
CS 618
B1
i=i+1
t2 = t2 + 4
B2
t3 = a[t2]
if t3 < v goto B2
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
a[t4] = t3
goto B2
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t1 = 4 n
t6 = a[t1]
a[t2] = t6
t1 = 4 n
a[t1] = t3
i=i+1
t2 = 4 i
B2
t3 = a[t2]
if t3 < v goto B2
July 2015
Strength Reduction and Induction Variable Elimination

i=m-1
j=n
t1 = 4 n
t6 = a[t1]
v = t6
t2 = 4 i
t4 = 4 j
15/57
17/57
Final Intermediate Code
B1
B2
B3
B6
i=i+1
t2 = t2 + 4
B2
t3 = a[t2]
if t3 < v goto B2
j=j-1
t4 = t4 4
B3
t5 = a[t4]
B5
if t5 > v goto B3
B4 if t2 >= t4 goto B6 B4
t2 = 4 i
t3 = a[t2]
x = t3
t2 = 4 i
t4 = 4 j
t5 = a[t4]
a[t2] = t5
t4 = 4 j
a[t4] = t3
goto B2
IIT Bombay
B5
CS 618
18/57
CS 618
Optimized Program Flow Graph
Nesting Level
0
1
2
19/57
Observations
No. of Statements
Original Optimized
14
10
11
4
8
6
Optimizations are transformations based on some information.

Systematic analysis required for deriving the information.
We have looked at data flow optimizations.
If we assume that a loop is executed 10 times, then the number of

computations saved at run time
Many control flow optimizations can also be performed.
= (14 10) + (11 4) 10 + (8 6) 102 = 4 + 70 + 200 = 274
July 2015
IIT Bombay
CS 618
July 2015
20/57
IIT Bombay
CS 618
Categories of Optimizing Transformations and Analyses
Code Motion
Redundancy Elimination Machine Independent
Control flow Optimization
Flow Analysis
(Data + Control)
Machine Dependent
Dependence Analysis
(Data + Control)
Instruction Scheduling
Register Allocation
Peephole Optimization
Machine Dependent
Several
Independent
Techniques
Vectorization
Parallelization
Machine Dependent
Dependence Analysis
(Data + Control)
Loop Transformations
What is Program Analysis?
Discovering information about a given program

Representing the dynamic behaviour of the program
Most often obtained without executing the program
July 2015
IIT Bombay
21/57
Static analysis Vs. Dynamic Analysis

Example of loop tiling for parallelization
Must represent all execution instances of the program
July 2015
IIT Bombay
CS 618
22/57
Why is it Useful?
Code optimization
Improving time, space, energy, or power efficiency

Compilation for special architecture (eg. multicore)
Verification and validation

Giving guarantees such as: The program will
Part 3
never divide a number by zero

never dereference a NULL pointer
close all opened files, all opened socket connections
not allow buffer overflow security violation
Optimizing Heap Memory Usage
Software engineering
Maintenance, bug fixes, enhancements, migration

Example: Y2K problem
Reverse engineering
To understand the program
July 2015
IIT Bombay
Intro to PA: Optimizing Heap Memory Usage
CS 618
23/57
CS 618
Standard Memory Architecture of Programs
Managing Heap Memory
Decision 1: When to Allocate?
Static Data
Heap allocation provides the flexibility of

Stack
Variable Sizes. Data structures can grow or

shrink as desired at runtime.
(Not bound to the declarations in program.)
Heap
24/57
Variable Lifetimes. Data structures can be

created and destroyed as desired at runtime.
Code
Explicit. Specified in the programs. (eg. Imperative/OO languages)

Implicit. Decided by the language processors. (eg. Declarative Languages)
Decision 2: When to Deallocate?

Explicit. Manual Memory Management (eg. C/C++)
Implicit. Automatic Memory Management aka Garbage Collection (eg.
Java/Declarative languages)
(Not bound to the activations of procedures.)
July 2015
IIT Bombay
July 2015
IIT Bombay
CS 618
25/57
CS 618
Garbage Collection Automatic Deallocation
State of Art in Manual Deallocation
Memory leaks
Retain active data structure.
10% to 20% of last development effort goes in plugging leaks
Deallocate inactive data structure.
Tool assisted manual plugging
What is an Active Data Structure?
Purify, Electric Fence, RootCause, GlowCode, yakTest, Leak Tracer, BDW

Garbage Collector, mtrace, memwatch, dmalloc etc.
If an object does not have an access path, (i.e. it is unreachable)

then its memory can be reclaimed.
All leak detectors
are dynamic (and hence specific to execution instances)

generate massive reports to be perused by programmers
usually do not locate last use but only allocation escaping a call
At which program point should a leak be plugged?
July 2015
What if an object has an access path, but is not accessed after the
given program point?
IIT Bombay
CS 618
26/57
July 2015
27/57
CS 618
What is Garbage?
IIT Bombay
28/57
Is Reachable Same as Live?

Garbage
r
r pt
z = New class of z
y = y.lptr
z.sum = x.data + y.data
l pt
r
tr
5
6
7
b
rp
w=x
// x points to ma
if (x.data < max)
x = x.rptr
y = x.lptr
rptr
lptr
rptr
lptr
rptr
lptr
rptr
lptr
a
w
y
r
l pt
1
2
3
4
r
r pt
i
q
l pt
r
Garbage
Stack
From www.memorymanagement.org/glossary
live (also known as alive, active) : Memory(2) or an object is live if the
program will read from it in future. The term is often used more broadly to
mean reachable.
It is not possible, in general, for garbage collectors to determine exactly which
objects are still live. Instead, they use some approximation to detect objects
that are provably dead, such as those that are not reachable.
Similar terms: reachable. Opposites: dead. See also: undead.
Heap
All white nodes are unused and should be considered garbage

July 2015
IIT Bombay
July 2015
IIT Bombay
CS 618
29/57
CS 618
Is Reachable Same as Live?
30/57
Reachability and Liveness
Comparison between different sets of objects:

Live
Not really. Most of us know that.
Reachable
Allocated
The objects that are not live must be reclaimed.
Even with the state of art of garbage collection, 24% to 76% unused
memory remains unclaimed
The state of art compilers, virtual machines, garbage collectors cannot
distinguish between the two
July 2015
CS 618
IIT Bombay
July 2015
30/57
CS 618
Reachable

Allocated
Live
Reachable
Allocated

Live
July 2015
30/57

Live
IIT Bombay
IIT Bombay
July 2015
Reachable
Allocated
IIT Bombay
CS 618
30/57
CS 618
Cedar Mesa Folk Wisdom

Make the unused memory unreachable by setting references to NULL. (GC
FAQ: http://www.iecc.com/gclist/GC-harder.html)
Reachable
Allocated
p
Reachable
z
Allocated
l pt
r
tr
Live
rp
Live
rptr
lptr
rptr
lptr
rptr
lptr
rptr
lptr
a
r
l pt
Garbage collectors
collect these
X
l pt
r
Stack
July 2015
IIT Bombay
CS 618
31/57
Heap
July 2015
32/57
IIT Bombay
CS 618
Cedar Mesa Folk Wisdom
33/57
Distinguishing Between Reachable and Live
The state of art

Most promising, simplest to understand, yet the hardest to implement.
Which references should be set to NULL?
Eliminating objects reachable from root variables which are not live.
Implemented in current Sun JVMs.
Most approaches rely on feedback from profiling.

No systematic and clean solution.
Uses liveness data flow analysis of root variables (stack data).

What about liveness of heap data?
July 2015
IIT Bombay
July 2015
IIT Bombay
CS 618
34/57
Liveness of Stack Data: An Informal Introduction
w=x
while (x.data < max)
x = x.rptr
CS 618
// x points to ma
Heap
w=x
// x points to ma
x = x.rptr
y = x.lptr
y = x.lptr
z = New class of z
z = New class of z
y = y.lptr
y = y.lptr
Stack
IIT Bombay
CS 618
w=x
x = x.rptr
34/57
y = x.lptr
5
6
7
Stack
CS 618
34/57
and reading its contents
rptr
Heap
rptr
w=x
x = x.rptr
// x points to ma
y = x.lptr
z = New class of z
z = New class of z
y = y.lptr
y = y.lptr
Stack
What is the
meaning of the use
of data?
July 2015
IIT Bombay
Accessing the location
lptr
rptr
data
rptr
// x points to ma
Heap
July 2015
rptr
lptr
rptr
data
What is the
meaning of the use
of data?
if changed to while
July 2015
34/57
rptr
lptr
rptr
data
Heap
rptr
Stack
Reading x (Stack data)
IIT Bombay
July 2015
IIT Bombay
CS 618
34/57
w=x
x = x.rptr
y = x.lptr
rptr
lptr
rptr
data
Heap
rptr
w=x
// x points to ma
x = x.rptr
y = x.lptr
z = New class of z
z = New class of z
y = y.lptr
y = y.lptr
Stack
Reading x.data (Heap data)
July 2015
w
w
x
x
y
y
z
z
35/57
w
w
x
x
y
y
z
z
Stack
CS 618
35/57

w
w
w
x
x
y
y
z
z
w
w
x
x
y
y
z
z

x = x.rptr
End of iteration #1
y = x.lptr
End of iteration #2
y = x.lptr
w
z = New class of z
z = New class of z
y = y.lptr
y = y.lptr
Live
w
July 2015
IIT Bombay
w=x

x = x.rptr
Heap
rptr
July 2015

w=x
rptr
lptr
rptr
data
Reading x.rptr (Heap data)
IIT Bombay
CS 618
34/57
// x points to ma
CS 618
Dead
IIT Bombay
Live
July 2015
Dead
IIT Bombay
36/57
CS 618
Applying Cedar Mesa Folk Wisdom to Heap Data
Liveness Analysis of Heap Data
If the while loop is not executed even once.
If the while loop is executed once.
l pt
r
tr
z = New class of z
y = y.lptr
lptr
b
rp
5
6
7
z
x
lptr
rptr
r
r pt
j
lptr
i
q
l pt
r
rptr
lptr
July 2015
CS 618
k
l
1
2
3
4
w=x
// x points to ma
x = x.rptr
y = x.lptr
5
6
7
z = New class of z
y = y.lptr
36/57
r
r pt
p
z
b
tr
l pt
r
rp
rptr
lptr
rptr
lptr
rptr
lptr
rptr
lptr
r
l pt
Stack
July 2015
lptr
rptr
lptr
rptr
lptr
rptr
lptr
a
w
y
r
r pt
i
q
l pt
r
Heap
IIT Bombay
CS 618
37/57
Mappings between access expressions and l-values keep changing
If the while loop is executed twice.
z = New class of z
y = y.lptr
rptr
The Moral of the Story
5
6
7
l pt
r
July 2015
w=x
// x points to ma
x = x.rptr
y = x.lptr
Stack
IIT Bombay
1
2
3
4
Heap
Stack
r
r pt
rptr
a
w
r
l pt
w=x
// x points to ma
x = x.rptr
y = x.lptr
r
l pt
1
2
3
4
rptr
tr
r
r pt
36/57
rp
CS 618
r
r pt
i
q
l pt
r
This is a rule for heap data
For stack and static data, it is an exception!
Static analysis of programs has made significant progress for stack and
static data.
What about heap data?
Given two access expressions at a program point, do they have the

same l-value?
Given the same access expression at two program points, does it have
the same l-value?
Heap
IIT Bombay
July 2015
IIT Bombay
38/57
CS 618
y = z = null
w = null
x.lptr = null
x.rptr = x.lptr.rptr = null
x.lptr.lptr.lptr = null
x.lptr.lptr.rptr = null
4 y = x.lptr
x.lptr = y.rptr = null
y.lptr.lptr = y.lptr.rptr = null
5 z = New class of z
z.lptr = z.rptr = null
6 y = y.lptr
y.lptr = y.rptr = null
7 z.sum = x.data + y.data
While loop is not executed even once
r
r pt
p
z
l pt
r
rptr
lptr
rptr
lptr
rptr
lptr
rptr
lptr
b
f
a
w
r
l pt
y = z = null
1 w=x
w = null
2 while (x.data < max)
{
x.lptr = null
3
x = x.rptr
}
4 y = x.lptr
6 y = y.lptr
x = y = z = null
1 w=x
{
3
x = x.rptr
}
39/57
Our Solution
tr
Our Solution
rp
CS 618
r
r pt
l pt
r
Heap
Stack
x = y = z = null
July 2015
IIT Bombay
39/57
IIT Bombay
CS 618
July 2015
While loop is executed once

rptr
lptr
b
tr
lptr
a
rptr
w
r
r pt
lptr
l pt
r
h
k
rptr
l
n
m
lptr
Stack
i
q
g
f
rp
y = z = null
1 w=x
w = null
{
x.lptr = null
3
x = x.rptr
}
4 y = x.lptr
6 y = y.lptr
x = y = z = null
39/57
Our Solution
Heap
IIT Bombay
y = z = null
1 w=x
w = null
{
x.lptr = null
3
x = x.rptr
}
4 y = x.lptr
6 y = y.lptr
x = y = z = null
July 2015
While loop is executed twice
r
r pt
p
z
x
b
tr
Our Solution
rp
CS 618
July 2015
rptr
lptr
rptr
lptr
rptr
lptr
a
w
r
r pt
Stack
i
q
l pt
r
Heap
IIT Bombay
40/57
CS 618
Some Observations
r
r pt
p
b
tr
l pt
r
rptr
lptr
rptr
lptr
rptr
lptr
rptr
lptr
a
w
r
r pt
i
q
l pt
r
Heap
Stack
July 2015
IIT Bombay
CS 618
40/57
July 2015
rptr
rp
tr
l pt
r
lptr
rptr
lptr
a
rptr
w
r
r pt
l pt
r
lptr
g
h
k
rptr
l
n
m
lptr
Stack
i
q
Heap
Stack
IIT Bombay
CS 618
40/57
Some Observations
r
r pt
execution reaches a given program point is

not an invariant of program execution
rptrof x d
Whether we dereference lptr out
or
c
r program point is an
rptr out ofp x at a given
t
p
lptr
r
e
invariant
of program execution
z
b
g
A static analysis can lpdiscover
rptr some
only
tr
f
invariants
lptr
x
h
a
k
rptr
w
j
r
t
rp
lptr
l
i
y
n
l pt
rptr
q
r
m
lptr
o
July 2015
Some Observations
y = z = null
1 w=x
w = null
{
x.lptr = null
3
x = x.rptr
}
4 y = x.lptr
6 y = y.lptr
x = y = z = null
The memory address that x holds when the
Heap
IIT Bombay
y = z = null
1 w=x
w = null
{
x.lptr = null
3
x = x.rptr
}
4 y = x.lptr
6 y = y.lptr
x = y = z = null
July 2015
r
r pt
p
z
l pt
r
rptr
lptr
rptr
lptr
rptr
lptr
rptr
lptr
b
tr
y = z = null
1 w=x
w = null
{
x.lptr = null
3
x = x.rptr
}
4 y = x.lptr
6 y = y.lptr
x = y = z = null
is nullified
tr
ai
Node i is live but link
rp
y = z = null
1 w=x
w = null
{
x.lptr = null
3
x = x.rptr
}
4 y = x.lptr
6 y = y.lptr
x = y = z = null
40/57
rp
Some Observations
rp
CS 618
a
w
r
r pt
Stack
i
q
l pt
r
Heap
IIT Bombay
CS 618
40/57
Some Observations
New access expressions are created.
Can they cause exceptions?
r
r pt
p
z
tr
l pt
r
rptr
lptr
rptr
lptr
rptr
lptr
rptr
lptr
a
w
r
r pt
Stack
July 2015
l pt
r
Concrete, Unbounded,
Infinitely Many
Static
Dynamic
Program Code
Program
Execution
Program
Execution
Program
Execution
Program
Execution
Program
Program Execution
Execution
Static
Analysis
i
q
Abstract, Bounded,
Single Instance
41/57
BTW, What is Static Analysis of Heap?
rp
y = z = null
1 w=x
w = null
{
x.lptr = null
3
x = x.rptr
}
4 y = x.lptr
6 y = y.lptr
x = y = z = null
CS 618
Summary
Heap Data
Profiling
Heap
Memory
Heap
Memory
Heap
Memory
Heap
Memory
Heap
Memory
Heap
Memory
Heap
Memory
Heap
Memory
Heap
Memory
Heap
Heap
Heap
Memory
Memory
Heap Memory
Memory
Heap
Memory
Heap
Memory
Heap
Memory
Heap
Heap
Memory
Memory
Heap
Heap
Memory
Memory
Heap
Memory
Heap
Memory
Heap
Heap Memory
Memory
Heap
IIT Bombay
July 2015
IIT Bombay
CS 618
42/57
Intro to PA: Course Details
The Main Theme of the Course

Constructing
Part 4
suitable abstractions for

sound & precise modelling of
runtime behaviour of programs
efficiently
Abstract, Bounded, Single Instance

Static
Course Details
Dynamic
Program Code
Static
Analysis
Summary Information
July 2015
Concrete, Unbounded, Infinitely Many
Program
Execution
Program
Execution
Program
Execution
Program
Execution
Program
Program Execution
Execution
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
Memory
IIT Bombay
CS 618
43/57
CS 618
Sequence of Generalizations in the Course Modules
43/57
Bit Vector
Frameworks
Bit Vector
Frameworks
Theoretical abstractions
July 2015
IIT Bombay
CS 618
July 2015
43/57
IIT Bombay
CS 618
43/57

Intraprocedural Level
w
o
fr
a
dfl
m
ta
e
w
o
rk s G
t da
eneral d fra meworks dada
ework
July 2015
d d fl
ne
fra m
Bit Vector
Frameworks
r al
fra m
ework
d d fl
w
o
fr
a
dfl
m
ta
e
w
o
rk s G
t da
eneral d fra meworks dada
fl o w G e
fl o w G e
r al
w
ne
Bit Vector
Frameworks
IIT Bombay
July 2015
IIT Bombay
CS 618
43/57
CS 618

Intraprocedural Level
Course Pedagogy
Interprocedural Level
Interleaved lectures and tutorials
w
o
fra
dfl
m
e
ata
work
at d
s G e n er
al d fra meworks dad
Practice problems will be provided,
fra m
ework
d d fl
fl o w G e
Bit Vector
Frameworks
r al
Plenty of problem solving
w
ne
44/57
Readymade solutions will not be provided

Your solutions will be checked
Detailed course plan can be found at the course page:
http://www.cse.iitb.ac.in/uday/courses/cs618-15/
Moodle will be used extensively for announcements and discussions

July 2015
IIT Bombay
CS 618
July 2015
45/57
IIT Bombay
CS 618
Assessment Scheme
Course Strength and Selection Criteria
Tentative plan
Mid Semester Examination
End Semester Examination
Two Quizzes
Programming Project
Total
46/57
Unavailability of TAs forces restricting the strength to 30
30%
40%
10%
20%
100%
(No offering in 2014)
Selection based on a test covering the concepts in the first lecture

May allow a reasonable many audits
Can be fine tuned based on the class feedback
GCC based projets
Attending all lectures is sufficient

No need to appear in examinations or do projects
(Short introduction of GCC will be covered)
July 2015
IIT Bombay
July 2015
IIT Bombay
CS 618
47/57
Questions ??
See you on Friday 24 July . . .
Part 5
Soundness and Precision
for your first enounter with a test in this semester
July 2015
CS 618
IIT Bombay
48/57
Intro to PA: Soundness and Precision
CS 618
Soundness and Precision of Static Analysis

Example Program
Control Flow Graph
Absolute
int a;
int f(int b)
{ int c;
c = a%2;
b = - abs(b);
while (b < c)
b = b+1;
if (b > 0)
b = 0;
return b;
}
c = a%2
1 b = - abs(b)
Execution Traces for Concrete Semantics

A state: (Program Point, Variables
7 Values)
A trace: a valid sequence of states starting with a given initial state
c = a%2
1 b = - abs(b)
2 if (b<c)
F
4 if (b>0)
F
2 if (b<c)
T
3 b = b+1
T
5 b = 0
F
4 if (b>0)
F
IIT Bombay
return b
July 2015
T
3 b = b+1
T
5 b = 0
return b
6
July 2015
49/57
Trace 1
a b c
Entry1 , (5, 2, 7)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry3 , (5, 1, 1)
Entry2 , (5, 0, 1)
Entry3 , (5, 0, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
Entry6 , (5, 0, 1)
Trace 1
a b c
Entry1 , (5, 2, 8)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry6 , (5, 1, 1)
IIT Bombay
CS 618
49/57
CS 618
Execution Traces for Concrete Semantics
50/57
Static Analysis Computes Abstractions of Traces (1)
A state: (Program Point, Variables

7 Values)
A trace: a valid sequence of states starting with a given initial state
Trace 1
Trace 1
a b c
a b c
Entry1 , (5, 2, 7)
Entry1 , (5, 2, 8)
A separate trace forEntry
each
combination of inputs
2 , (5, 2, 1) Entry2 , (5, 2, 1)
2 if (b<c)
2, 1) Entry
The number of Entry
traces3 ,is(5,potentially
infinite
3 , (5, 2, 1)
Entry
,
(5,
1,
1)
Entry
, (5, 1, 1)
2
F Program
T
points may repeat
in the traces 2
Entry
,
(5,
1,
1)
Entry
3
4 , (5, 1, 1)
4 if (b>0) 3 b = b+1
Traces may be Entry
very long
Entry6 , (5, 1, 1)
2 , (5, 0, 1)
Non-terminating traces: Infinitely long
T
Entry3 , (5, 0, 1)
F
5 b = 0
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
6 return b
Entry6 , (5, 0, 1)
Traces
An Abstraction of Traces
c = a%2
1 b = - abs(b)
July 2015
IIT Bombay
CS 618
July 2015
50/57
Execution
Time
CS 618

Traces

A possible static abstraction using sets
Trace 1
a b c
Entry1 , (5, 2, 7)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry3 , (5, 1, 1)
Entry2 , (5, 0, 1)
Entry3 , (5, 0, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
Entry6 , (5, 0, 1)
compute a set of states

that cover all traces
associate the sets with
appropriate program points
States may be defined in terms
of properties derived from values
of variables
{(5, 2, 7), (5, 2, 8)}
IIT Bombay
July 2015
c = a%2
b = - abs(b)
1
Trace 1
a b c
Entry1 , (5, 2, 8)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1) 4
Entry4 , (5, 1, 1)
Entry6 , (5, 1, 1)
if (b<c)
F
if (b>0)
T
3
b = b+1
T
F
6
July 2015
51/57
An Abstraction of Traces
For compile time modelling of

possible runtime behaviours of a
program
Execution
Time
IIT Bombay
5 b = 0
return b
IIT Bombay
CS 618
51/57
CS 618

Trace 1
a b c
Entry1 , (5, 2, 7)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry3 , (5, 1, 1)
Entry2 , (5, 0, 1)
Entry3 , (5, 0, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
Entry6 , (5, 0, 1)
a = {5, 5}, b = {2, 2}, c = {7, 8}
Trace 1
a b c
Entry1 , (5, 2, 8)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1) 4
Entry4 , (5, 1, 1)
Entry6 , (5, 1, 1)
F
if (b>0)
T
3
b = b+1
T
5 b = 0
if (b<c)
return b
July 2015
a = {5, 5}, b = {2, 2}, c = {7, 8}
July 2015
c = a%2
b = - abs(b)
Trace 1
b = {2, 1, 0, 1}
a b c
2 if (b<c)
Entry1 , (5, 2, 8)
Entry2 , (5, 2, 1)
F
bT= {2, 1, 0}
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1) 4 if (b>0)
3 b = b+1
Entry4 , (5, 1, 1)
T
Entry6 , (5, 1, 1)
Trace 1
b = {2, 1, 0, 1}
a b c
2 if (b<c)
Entry1 , (5, 2, 8)
Entry2 , (5, 2, 1)
F
T
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1) 4 if (b>0)
3 b = b+1
Entry4 , (5, 1, 1)
T
Entry6 , (5, 1, 1)
5 b = 0
return b
51/57

Trace 1
a b c
Entry1 , (5, 2, 7)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry3 , (5, 1, 1)
Entry2 , (5, 0, 1)
Entry3 , (5, 0, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
Entry6 , (5, 0, 1)
return b
a = {5, 5}, b = {2, 2}, c = {7, 8}

1
July 2015
c = a%2
b = - abs(b)
Trace 1
b = {2, 1, 0, 1}
a b c
2 if (b<c)
Entry1 , (5, 2, 8)
Entry2 , (5, 2, 1)
F
bT= {2, 1, 0}
Entry3 , (5, 2, 1) b = {1, 1}
Entry2 , (5, 1, 1) 4 if (b>0)
3 b = b+1
Entry4 , (5, 1, 1)
T
Entry6 , (5, 1, 1)
F
6
IIT Bombay
5 b = 0
c = a%2
b = - abs(b)
IIT Bombay
CS 618
July 2015
51/57
Trace 1
a b c
Entry1 , (5, 2, 7)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry3 , (5, 1, 1)
Entry2 , (5, 0, 1)
Entry3 , (5, 0, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
Entry6 , (5, 0, 1)
a = {5, 5}, b = {2, 2}, c = {7, 8}
6
IIT Bombay
CS 618

Trace 1
a b c
Entry1 , (5, 2, 7)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry3 , (5, 1, 1)
Entry2 , (5, 0, 1)
Entry3 , (5, 0, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
Entry6 , (5, 0, 1)
c = a%2
b = - abs(b)
51/57
5 b = 0
return b
IIT Bombay
CS 618
51/57
CS 618

Trace 1
a b c
Entry1 , (5, 2, 7)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry3 , (5, 1, 1)
Entry2 , (5, 0, 1)
Entry3 , (5, 0, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
Entry6 , (5, 0, 1)
a = {5, 5}, b = {2, 2}, c = {7, 8}
Trace 1
a b c
Entry1 , (5, 2, 7)
Entry2 , (5, 2, 1)
Entry3 , (5, 2, 1)
Entry2 , (5, 1, 1)
Entry3 , (5, 1, 1)
Entry2 , (5, 0, 1)
Entry3 , (5, 0, 1)
Entry2 , (5, 1, 1)
Entry4 , (5, 1, 1)
Entry5 , (5, 1, 1)
Entry6 , (5, 0, 1)
c = a%2
b = - abs(b)
Trace 1
b = {2, 1, 0, 1}
a b c
2 if (b<c)
Entry1 , (5, 2, 8)
Entry2 , (5, 2, 1)
F
bT= {2, 1, 0}
Entry3 , (5, 2, 1) b = {1, 1}
Entry2 , (5, 1, 1) 4 if (b>0)
3 b = b+1
Entry4 , (5, 1, 1)
T b = {1}
Entry6 , (5, 1, 1)
5 b = 0
IIT Bombay
CS 618
53/57
Soundness of Abstractions (1)

Sound
return b
July 2015
52/57
5 b = 0
b = {1, 0}
6
IIT Bombay
c = a%2
b = - abs(b)
Trace 1
b = {2, 1, 0, 1}
a b c
2 if (b<c)
Entry1 , (5, 2, 8)
Entry2 , (5, 2, 1)
F
bT= {2, 1, 0}
Entry3 , (5, 2, 1) b = {1, 1}
Entry2 , (5, 1, 1) 4 if (b>0)
3 b = b+1
Entry4 , (5, 1, 1)
T b = {1}
Entry6 , (5, 1, 1)
return b
July 2015
CS 618
a = {5, 5}, b = {2, 2}, c = {7, 8}

1
51/57

An unsound abstraction
Unsound
a = {5, 5}, b = {2, 2}, c = {7, 8}

c = a%2
1 b = - abs(b)
All variables can have arbitrary
values at the start.
b = {2, 1, 0, 1}
2
An over-approximation
of traces is sound
if (b<c)
F
b = {1, 1}
Missing any state in

any trace causes
unsoundness
if (b>0)
bT= {2, 1, 0}
3
b = b+1
T b = {1}
5 b = 0
b can have many more values

at the entry of
blocks 2 and 3 (e.g. -3,
-8, . . . )
block 4 (e.g. 0)
b = {1, 0}
6
July 2015
IIT Bombay
return b
July 2015
IIT Bombay
CS 618
53/57
CS 618

A sound abstraction using intervals
a = {5, 5}, b = {2, 2}, c = {7, 8}

c = a%2
1 b = - abs(b)
b = {2, 1, 0, 1}
2
if (b<c)
F
b = {1, 1}
4
bT= {2, 1, 0}
if (b>0)
b = b+1
T b = {1}
5 b = 0
A sound abstraction using intervals
a = {5, 5}, b = {2, 2}, c = {7, 8}
a = [, ] , b = [, ] , c = [, ]
c = a%2
1 b = - abs(b)
Overapproximated range of
values denoted by

low limit, high limit
c = a%2
1 b = - abs(b)
b = {2, 1, 0, 1}
2
bT= {2, 1, 0}
if (b>0)
low limit high limit
b = [, 1]
if (b<c)
b = {1, 1}
Inclusive limits with
b = b+1
One continuous range per

variable with no holes
July 2015
IIT Bombay
CS 618
5 b = 0
More Precise
if (b>0)
b = b+1
5 b = 0
b = [1, 0]
return b
return b
IIT Bombay
CS 618
Precision of Sound Abstractions(1)

Imprecise
Tb = [, 0]
July 2015
54/57
T b = [1, 1]
b = {1, 0}
return b
if (b<c)
b = [1, 1]
T b = {1}
b = {1, 0}
6
53/57
54/57

Imprecise
Even More Precise
More Precise
Even More Precise
Precision is relative, soundness is absolute

Qualifiers more precise and less precise
are meaningful
Qualifiers more sound and less sound
are not meaningful
July 2015
IIT Bombay
July 2015
IIT Bombay
CS 618
55/57
CS 618

A precise abstraction using intervals
An imprecise abstraction using intervals
a = [, ] , b = [, ] , c = [, ] a = [, ] , b = [, ] , c = [, ]
c = a%2
1 b = - abs(b)
c = a%2
1 b = - abs(b)
b = [, 1]
b = [, ]
if (b<c)
F
b = [1, 1]
4
if (b>0)
b = b+1
if (b>0)
T b = [1, 1]
F
5 b = 0
return b
c = a%2
c = a%2
1 b = - abs(b)
1 b = - abs(b)
In general, computation of precise (or exact)
b = [, 1]static abstraction is undecidableb = [, ]
2
Tb = [, ]
3
b = b+1
5 b = 0
of0]static analysis
in ]
minimizing
F Goodness
F
Tb = [,
Tb = [, ]
b =lies
[,
imprecision without compromising on soundness
if (b>0)
4 if (b>0)
3 b = b+1
3 b = b+1
Additional expectations: Efficiency and scalability
T b =
T not
[1, 1]applications (e.g. debugging) may
b = [, ]
Some
5 b = 0 need soundness
return b
6
IIT Bombay
5 b = 0
b = [, ]
b = [1, 0]
return b
July 2015
We have to settle for some imprecision

if (b<c)
2 if (b<c)
b = [1, 1]
b = [, ]
6
An imprecise abstraction using intervals
a = [, ] , b = [, ] , c = [, ] a = [, ] , b = [, ] , c = [, ]
T b = [, ]
b = [1, 0]
6
A precise abstraction using intervals
if (b<c)
b = [, ] F
Tb = [, 0]
55/57
return b
July 2015
IIT Bombay
Intro to PA: Program Model
CS 618
56/57
Program Representation
Three address code statements
Part 6
Program Model
Result, operator, operand1, operand2

Assignments, expressions, conditional jumps
Intially only scalars
Pointers, structures, arrays modelled later
Control flow graph representation
Nodes represent maximal groups of statements

devoid of any control transfer except fall through
Edges represent control transfers across basic blocks
A unique Start node and a unique End node
Every node reachable from Start, and End reachable from every node
Initially only intraprocedural programs

Function calls brought in later
July 2015
IIT Bombay
Intro to PA: Program Model
CS 618
57/57
An Example Program
int main()
{ int a, b, c, n;
a = 4;
b = 2;
c = 3;
n = c*2;
while (a <= n)
{
a = a+1;
}
if (a < 12)
a = a+b+c;
return a;
}
July 2015
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
a = 4
b = 2
c = 3
n = c*2
if (a > n)
goto 8
a = a + 1
goto 5
if (a 12)
goto 11
t1 = a+b
a = t1+c
return a
a
b
c
n
=
=
=
=
4
2
n1
3
c*2
if (an) n2
T
a = a + 1 n3
F
if (a<12) n4
T
t1 = a+b
F
a = t1+c n5
return a n6
IIT Bombay

Dfa Motivation Handout

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dfa Motivation Handout

Uploaded by

Copyright:

Available Formats

Introduction to Program Analysis

Department of Computer Science and Engineering,

About These Slides

Indian Institute of Technology, Bombay

Intro to PA: About These Slides

Intro to PA: Outline

Motivating the Need of Program Analysis

Some representative examples

Classical optimizations performed by compilers

Course details, schedule, assessment policies etc.

Intro to PA: Classical Optimizations

Examples of Optimising Transformations (ALSU, 2006)

Intermediate Code : Observations

For the boxed source code

Multiple computations of expressions

Array address calculations

Intro to PA: Classical Optimizations

Intro to PA: Classical Optimizations

Understanding Control Flow

Intermediate Code with Basic Blocks

Identify maximal sequences of linear control flow

14. if i >= j goto 25

Program Flow Graph : Observations

Program Flow Graph

Intro to PA: Classical Optimizations

Intro to PA: Classical Optimizations

Local Common Subexpression Elimination

Global Common Subexpression Elimination

Global Common Subexpression Elimination

Global Common Subexpression Elimination

Intro to PA: Classical Optimizations

Intro to PA: Classical Optimizations

Other Classical Optimizations

Copy Propagation and Dead Code Elimination

Intro to PA: Classical Optimizations

Strength Reduction and Induction Variable Elimination

Final Intermediate Code

Intro to PA: Classical Optimizations

Intro to PA: Classical Optimizations

Optimized Program Flow Graph

Optimizations are transformations based on some information.

If we assume that a loop is executed 10 times, then the number of

Many control flow optimizations can also be performed.

= (14 10) + (11 4) 10 + (8 6) 102 = 4 + 70 + 200 = 274

Categories of Optimizing Transformations and Analyses

What is Program Analysis?

Discovering information about a given program

Static analysis Vs. Dynamic Analysis

Must represent all execution instances of the program

Intro to PA: Classical Optimizations

Improving time, space, energy, or power efficiency

Verification and validation

never divide a number by zero

Optimizing Heap Memory Usage

Maintenance, bug fixes, enhancements, migration

Intro to PA: Optimizing Heap Memory Usage

Standard Memory Architecture of Programs

Managing Heap Memory

Decision 1: When to Allocate?

Heap allocation provides the flexibility of

Variable Sizes. Data structures can grow or

Variable Lifetimes. Data structures can be

Explicit. Specified in the programs. (eg. Imperative/OO languages)

Decision 2: When to Deallocate?