Software Verification

Software Verification Grégoire Sutre LaBRI, University of Bordeaux, CNRS, France

Summer School on Verification Technology, Systems & Applications September 2008 Part 1

Grégoire Sutre

Software Verification

VTSA’08

1 / 286

Part I Introduction

Grégoire Sutre


Introduction

VTSA’08

2 / 286

Outline — Introduction

1

Software Verification: Why?

2

Software Verification: How?

Grégoire Sutre


Introduction

VTSA’08

3 / 286


1


2


Grégoire Sutre


Introduction

VTSA’08

4 / 286

Ubiquity of Software in Modern Life Once upon a time, lecturers used hand-written transparencies with an overhead projector. pens

lamp

transparencies

lenses

scissors

mirror

sticky tape

screen

Nowadays softwares are used to design the slides and to project them Similar evolution in many, many areas Grégoire Sutre


Introduction

VTSA’08

5 / 286

Ubiquity of Software in Modern Life Once upon a time, lecturers used hand-written transparencies with an overhead projector. pens

lamp

transparencies

lenses

scissors

mirror

sticky tape

screen

Nowadays softwares are used to design the slides and to project them Similar evolution in many, many areas Grégoire Sutre


Introduction

VTSA’08

5 / 286

Why? Some advantages of software over dedicated hardware components Reduce time to market Less time to write the slides (really?) Ability to re-organize the presentation

Reduce costs No pen, no transparencies Re-usability of slides, ability to make minor modifications for free

Increase functionality Automatic generation of some slides (table of contents) Nicer overlays (sticky tape is not required anymore!) Ability to display videos

But software is not without risk. . . Grégoire Sutre


Introduction

VTSA’08

6 / 286

Bugs are Frequent in Software

Grégoire Sutre


Introduction

VTSA’08

7 / 286


Grégoire Sutre


Introduction

VTSA’08

7 / 286


Grégoire Sutre


Introduction

VTSA’08

7 / 286


Grégoire Sutre


Introduction

VTSA’08

7 / 286


Grégoire Sutre


Introduction

VTSA’08

7 / 286


Grégoire Sutre


Introduction

VTSA’08

7 / 286

A Critical Software Bug: Ariane 5.01 « On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded. » « The failure of the Ariane 5.01 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift-off). This loss of information was due to specification and design errors in the software of the inertial reference system. » Grégoire Sutre


Introduction

VTSA’08

8 / 286

A Critical Software Bug: Ariane 5.01 « On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded. » « The failure of the Ariane 5.01 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift-off). This loss of information was due to specification and design errors in the software of the inertial reference system. » Grégoire Sutre


Introduction

VTSA’08

8 / 286

Software in Embedded Systems Embedded systems in: cell phones, satellites, airplanes, cars, wireless routers, MP3 players, refrigerators, . . .

Examples of Critical Systems attitude and orbit control systems in satellites X-by-wire control systems in airplanes and in cars (soon) Increasing importance of software in embedded systems custom hardware replaced by processor + custom software software is a dominant factor in design time and cost (70 %)

Critical embedded systems require “exhaustive” validation Grégoire Sutre


Introduction

VTSA’08

9 / 286

Software Complexity Grows Exponentially As computational power grows . . . Moore’s law: « the number of transistors on a chip doubles every two years » . . . software complexity grows . . . Wirth’s Law: « software gets slower faster than hardware gets faster » . . . and so does the number of bugs! Watts S. Humphrey: « 5 – 10 bugs per 1000 lines of code after product test » Growing need for automatic validation techniques

Grégoire Sutre


Introduction

VTSA’08

10 / 286


Grégoire Sutre


Introduction

VTSA’08

10 / 286


Grégoire Sutre


Introduction

VTSA’08

10 / 286


Grégoire Sutre


Introduction

VTSA’08

10 / 286


1


2


Grégoire Sutre


Introduction

VTSA’08

11 / 286

Software Testing Running the executable (obtained by compilation) on multiple inputs usually on the target platform Testing is a widespread validation approach in the software industry can be (partially) automated can detect a lot of bugs But Costly and time-consuming

Grégoire Sutre


Not exhaustive

Introduction

VTSA’08

12 / 286

Software Testing Running the executable (obtained by compilation) on multiple inputs usually on the target platform Testing is a widespread validation approach in the software industry can be (partially) automated can detect a lot of bugs But Costly and time-consuming

Grégoire Sutre


Not exhaustive

Introduction

VTSA’08

12 / 286

Dream of Software Model-Checking Model Checker x = 1; if (y 0


Introduction

VTSA’08

20 / 286

Abstract Interpretation Example: Sign Analysis 1

x = 1;

2

if (y ≤ 10) { y = 10;

3 4

}

5

else { while (x < y) {

6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12

assert(x > 0); Grégoire Sutre


Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0

y = 10;

3 4

}

5


6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12



Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5


6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12



Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12



Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12



Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1;

x>0 ∧ y>0

}

9 10

}

11

x = y + 1;

12



Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1;

x>0 ∧ y>0 x>0 ∧ y>0

}

9 10

}

11

x = y + 1;

12



Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1;

x>0 ∧ y>0 x>0 ∧ y>0 x>0 ∧ y≥0

}

9 10

}

11

x = y + 1;

12



Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1;

x>0 ∧ y>0

W

x>0 ∧ y≥0 ∧ x0 ∧ y>0 x>0 ∧ y≥0

}

9 10

}

11

x = y + 1;

12



Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12


x>0 ∧ y>0

W

x>0 ∧ y≥0 ∧ x0 ∧ y>0 x>0 ∧ y≥0 x>0 ∧ y≥0


Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12


x>0 ∧ y>0

W

x>0 ∧ y≥0 ∧ x0 ∧ y>0 x>0 ∧ y≥0 x>0 ∧ y≥0 x>0 ∧ y≥0


(x > 0 ∧ y > 0)

Introduction

W

(x > 0 ∧ y ≥ 0)

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12


x>0 ∧ y>0

W

x>0 ∧ y≥0 ∧ x0 ∧ y>0 x>0 ∧ y≥0 x>0 ∧ y≥0 x>0 ∧ y≥0

(x > 0 ∧ y > 0)

W

(x > 0 ∧ y ≥ 0)

x>0 ∧ y≥0


Introduction

VTSA’08

21 / 286


x = 1;

2

if (y ≤ 10) {

x>0 x>0

y = 10;

3 4

}

5

else {

x>0 ∧ y>0

x>0 ∧ y>0

while (x < y) {

6 7

x = 2 * x;

8

y = y - 1; }

9 10

}

11

x = y + 1;

12


x>0 ∧ y>0

W

x>0 ∧ y≥0 ∧ x0 ∧ y>0 x>0 ∧ y≥0 x>0 ∧ y≥0 x>0 ∧ y≥0

(x > 0 ∧ y > 0)

W

(x > 0 ∧ y ≥ 0)

x>0 ∧ y≥0

,


Introduction

VTSA’08

21 / 286

Credits: Pioneers (1970’s) Iterative Data Flow Analysis Gary Kildall John Kam & Jeffrey Ullman Michael Karr ...

Abstract Interpretation Patrick Cousot & Radhia Cousot Nicolas Halbwachs ... And many, many more. . . Grégoire Sutre


Apologies! Introduction

VTSA’08

22 / 286

Outline of the Lecture

Control Flow Automata

Data Flow Analysis

Abstract Interpretation

Abstract Model Refinement

Grégoire Sutre


Introduction

VTSA’08

23 / 286



Data Flow Analysis Static Analysis Abstract Interpretation

Abstract Model Refinement

Grégoire Sutre


Introduction

VTSA’08

23 / 286



Data Flow Analysis Static Analysis Abstract Interpretation Abstraction Refinement Abstract Model Refinement

Grégoire Sutre


Introduction

VTSA’08

23 / 286

Part II Control Flow Automata

Grégoire Sutre



VTSA’08

24 / 286

Outline — Control Flow Automata

3

Syntax and Semantics

4

Verification of Control Flow Automata

Grégoire Sutre



VTSA’08

25 / 286

Outline — Control Flow Automata

3

Syntax and Semantics

4

Verification of Control Flow Automata

Grégoire Sutre



VTSA’08

26 / 286

Short Introduction to Control Flow Automata Requirement for verification: formal semantics of programs

Formal Semantics Formalization as a mathematical model of the meaning of programs Denotational

Operational

Axiomatic

Operational Semantics Labeled transition system describing the possible computational steps

First Step Towards an Operational Semantics Program text

Grégoire Sutre

−→

Graph-based representation



VTSA’08

27 / 286



Operational

Axiomatic



Grégoire Sutre

−→




VTSA’08

27 / 286



Operational

Axiomatic



Grégoire Sutre

−→




VTSA’08

27 / 286



Operational

Axiomatic



Grégoire Sutre

−→

Graph-based representation Control flow automaton



VTSA’08

27 / 286

Control Flow Graph Start

1 2 3 4 5 6 7 8 9 10 11

x = 1; if (y ≤ 10) { y = 10; } else { while (x < y) { x = 2 * x; y = y - 1; } } x = y + 1;

x := 1

true

y := 10

y≤10

false

false

x := y+1

x10 q6

y := y-1 x10 q6

y := y-1

qin = q1 qout = q12

x10 , q6 ),      (q3 ,y := 10, q11 ),    ...


VTSA’08

32 / 286

Programs as Control Flow Automata Control flow automata can model: , flow of control (program points),

, numerical variables and numerical operations,

, non-determinism (uninitialized variables, boolean inputs). Control flow automata cannot model: / pointers

/ recursion / threads / ...

But they are complex enough for verification. . .

Grégoire Sutre



. . . and for learning!

VTSA’08

33 / 286



, non-determinism (uninitialized variables, boolean inputs). Control flow automata cannot model: / pointers

/ recursion / threads / ...


Grégoire Sutre




VTSA’08

33 / 286



, non-determinism (uninitialized variables, boolean inputs). Control flow automata cannot model:

...

/ pointers

/ recursion / threads

hese t t u o et ab

Forg

/ ...


Grégoire Sutre




VTSA’08

33 / 286

Verification of Safety Properties Goal Check that “nothing bad can happen”. Bad behaviors specified e.g. as assertion violations in the original program An assertion violation can be modeled as a location: assert(x > 0)

=⇒

if (x > 0) then { BAD: }

Goal (refined) Check that there is no “run” that visits a location q contained in a given set QBAD ⊆ Q of bad locations. Grégoire Sutre



VTSA’08

34 / 286


=⇒





VTSA’08

34 / 286


=⇒





VTSA’08

34 / 286

Runs: Examples q1

(q1 , 0, 0)

x := 1 y≤10

q2

q3

x := 1 (q2 , 1, 0)

y>10 q6

y := y-1 y≤10 x10

y>10 q6

y := y-1 x Je2 Kv

VTSA’08

37 / 286

Semantics of Expressions and Guards Consider a finite set X of variables. A valuation is a function v : X → R.

Expressions:

JeKv

Guards:

v |= g

[c ∈ Q]

v |= e1 < e2

if

= v (x) [x ∈ X]

v |= e1 ≤ e2

if

Je1 + e2 Kv

= Je1 Kv + Je2 Kv

v |= e1 = e2

if

v |= e1 6= e2

if

Je1 * e2 Kv

= Je1 Kv × Je2 Kv

v |= e1 ≥ e2

if

v |= e1 > e2

if

JcKv

JxKv

Je1 - e2 Kv

Grégoire Sutre

= c

= Je1 Kv − Je2 Kv



Je1 Kv < Je2 Kv

Je1 Kv ≤ Je2 Kv

Je1 Kv = Je2 Kv

Je1 Kv 6= Je2 Kv

Je1 Kv ≥ Je2 Kv

Je1 Kv > Je2 Kv

VTSA’08

37 / 286

Semantics of Operations The semantics JopK of an operation op is defined as a binary relation between valuations before op and valuations after op: JopK

⊆

(X → R) × (X → R)

Examples with X = {x, y} Jx*y ≤ 10K = {(v , v ) | v (x) × v (y) ≤ 10}

Jx := 3*xK = {(v , v 0 ) | v 0 (x) = 3 × v (x) ∧ v 0 (y) = v (y)}

Operations:

JopK

(v , v 0 ) ∈ JgK if (v , v 0 ) ∈ Jx := eK if Grégoire Sutre

v |= g and v 0 = v ( v 0 (x) = JeKv

v 0 (y ) = v 0 (y ) for all y 6= x



VTSA’08

38 / 286


⊆

(X → R) × (X → R)


Jx := 3*xK = {(v , v 0 ) | v 0 (x) = 3 × v (x) ∧ v 0 (y) = v (y)}

Operations:

JopK


v |= g and v 0 = v ( v 0 (x) = JeKv

v 0 (y ) = v 0 (y ) for all y 6= x



VTSA’08

38 / 286


⊆

(X → R) × (X → R)


Jx := 3*xK = {(v , v 0 ) | v 0 (x) = 3 × v (x) ∧ v 0 (y) = v (y)}

Operations:

JopK


v |= g and v 0 = v ( v 0 (x) = JeKv

v 0 (y ) = v 0 (y ) for all y 6= x



VTSA’08

38 / 286

Operational Semantics of Control Flow Automata Definition The interpretation of a control flow automaton hQ, qin , qout , X, →i is the labeled transition system hC, Init, Out, Op, →i defined by: C = Q × (X → R)

Init = {qin } × (X → R) and Out = {qout } × (X → R) op

op

(q, v ) −→ (q 0 , v 0 ) if q −→ q 0 and (v , v 0 ) ∈ JopK Two kinds of labeled directed graphs


Interpretations (LTS)

Use: program source codes

Use: program behaviors

Syntactic objects

Semantic objects

Finite

Uncountably infinite

Grégoire Sutre



VTSA’08

39 / 286

Operational Semantics of Control Flow Automata Definition The interpretation of a control flow automaton hQ, qin , qout , X, →i is the labeled transition system hC, Init, Out, Op, →i defined by: C = Q × (X → R)

Init = {qin } × (X → R) and Out = {qout } × (X → R) op

op

(q, v ) −→ (q 0 , v 0 ) if q −→ q 0 and (v , v 0 ) ∈ JopK Two kinds of labeled directed graphs


Interpretations (LTS)

Use: program source codes

Use: program behaviors

Syntactic objects

Semantic objects

Finite

Uncountably infinite

Grégoire Sutre



VTSA’08

39 / 286

Control Paths, Execution Paths and Runs A control path is a path in the control flow automaton: op

opk −1

0 q0 −−→ q1 · · · qk −1 −−−−→ qk

An execution path is a path in the labeled transition system: opk −1

op

0 (q0 , v0 ) −−→ (q1 , v1 ) · · · (qk −1 , vk −1 ) −−−−→ (qk , vk )

A run is an execution path that starts with an initial configuration: opk −1

op

0 (qin , vin ) −−→ (q1 , v1 ) · · · (qk −1 , vk −1 ) −−−−→ (qk , vk )

Grégoire Sutre



VTSA’08

40 / 286

Control Paths, Execution Paths and Runs A control path is a path in the control flow automaton: op

opk −1

0 q0 −−→ q1 · · · qk −1 −−−−→ qk

An execution path is a path in the labeled transition system: opk −1

op

0 (q0 , v0 ) −−→ (q1 , v1 ) · · · (qk −1 , vk −1 ) −−−−→ (qk , vk )

A run is an execution path that starts with an initial configuration: opk −1

op

0 (qin , vin ) −−→ (q1 , v1 ) · · · (qk −1 , vk −1 ) −−−−→ (qk , vk )

Grégoire Sutre



VTSA’08

40 / 286

Execution Path: Example (q1 , −159, 27)

q1

x := 1 (q2 , 1, 27)

x := 1 y≤10

q2

q3

y>10

y>10 q6

y := y-1 x10 q6

y := y-1

x10 q6

y := y-1 x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10 y := y-1

q3

q6

x10

q3

a := b+1

q6 a10 a := b+1

q3

q6 a10 q6

y := y-1 x10 q6

y := y-1 x

y >

VTSA’08

64 / 286

Constant Propagation Analysis: Running Example 0 : Initialization 1 : Propagation (→)

q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1

y > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1

y > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1

y > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1

y > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1

y > > >

1

10

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1

y > > >

1

10

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1

y > > >

1 11

10 10

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1

y > > >

1 11

10 10

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1

y > > > >

1 11

10 10

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1

y > > > >

1 11

10 10

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1

y > > > >

1 11

10, > 10

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1

y > > > >

1 11

> 10

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1

y > > > >

1 11, 2

> 10, >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1

y > > > >

1 >

> >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1 1

y > > > > >

1 >

> >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1 1

y > > > > >

1 >

> >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1 1 2 1 >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1 1 2 1 >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 1, 2 1 2 1 >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 > 1 2 1 >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 > 1 2 1, > >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 > 1 2 > >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 > 1, > 2 > >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 > > 2 > >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 > > 2, > > >

y > > > > > > > >

VTSA’08

64 / 286


q1 x := 1 y≤10

q2

q3

y>10 q6

y := y-1 x 1 1 > > > > >

y > > > > > > > >

VTSA’08

64 / 286

Constant Propagation Analysis: Formulation Extend R with a new element > to account for non-constant values Extend +, − and × such that > is absorbent >+r >−r >×r

= r +> = > = r −> = > = r ×> = >

for r ∈ R ∪ {>}

Extend JeKv to valuations from X to R ∪ {>}

Domain of data flow “information”

D

Grégoire Sutre

=

X → (R ∪ {>})


Data Flow Analysis

VTSA’08

65 / 286

Constant Propagation Analysis: Formulation

D

=

X → (R ∪ {>})

System of equations: variables Cq for q ∈ Q, with Cq ∈ D Cq

=

O

fop Cq 0

C(qin ) = λ x . >

op

q 0 −→q

v ⊗ v

0

=

( v (y ) if v (y ) = v 0 (y ) λy . > otherwise

Functions fop ( v (y ) if y = 6 x fx:=e (v ) = λ y . JeKv if y = x Grégoire Sutre


Data Flow Analysis

fg (v ) = v VTSA’08

66 / 286

Constant Propagation Analysis: Formulation

D

=

X → (R ∪ {>})

System of equations: variables Cq for q ∈ Q, with Cq ∈ D Cq

=

O

fop Cq 0

C(qin ) = λ x . >

op

q 0 −→q

v ⊗ v

0

=

( v (y ) if v (y ) = v 0 (y ) λy . > otherwise

Functions fop ( v (y ) if y = 6 x fx:=e (v ) = λ y . JeKv if y = x Grégoire Sutre


Data Flow Analysis

fg (v ) = v VTSA’08

66 / 286

Constant Propagation Analysis: Applications Code Optimization Constant folding

e J e0

x := e q1

q2

q1

q2

For each variable y occurring in e, if y is constant at location q1 then we may replace y with its constant value in e.

This is sound since the analysis is conservative

Grégoire Sutre


Data Flow Analysis

VTSA’08

67 / 286

Common Form of Data Flow Equations Domain D of data flow “information” sets of variables, sets of expressions, valuations, . . .

Variables Dq for q ∈ Q, with value in D Dq holds data-flow information for location q

Dq

=

! f Dq 0

“Confluence” operator ! on D to merge data flow information ∪, ∩, ⊗, . . .

Functions f : D → D to model the effect of operations Grégoire Sutre


Data Flow Analysis

VTSA’08

68 / 286

Common Form of Data Flow Equations Domain D of data flow “information” sets of variables, sets of expressions, valuations, . . .


Dq

=

! f Dq 0




Data Flow Analysis

VTSA’08

68 / 286

Outline — Data Flow Analysis

5

Classical Data Flow Analyses

6

Basic Lattice Theory

7

Monotone Data Flow Analysis Frameworks

Grégoire Sutre


Data Flow Analysis

VTSA’08

69 / 286

Partial Order A partial order on a set L is any binary relation v ⊆ L × L satisfying for all x, y , z ∈ L: x vx

(reflexivity)

x vy ∧ y vx

=⇒

x =y

(antisymmetry)

x vy ∧ y vz

=⇒

x vz

(transitivity)

A partially ordered set is any pair (L, v) where L is a set and v is a partial order on L. There can be x and y in L such that x 6v y and y 6v x.

Grégoire Sutre


Data Flow Analysis

VTSA’08

70 / 286

Partial Order A partial order on a set L is any binary relation v ⊆ L × L satisfying for all x, y , z ∈ L: x vx

(reflexivity)

x vy ∧ y vx

=⇒

x =y

(antisymmetry)

x vy ∧ y vz

=⇒

x vz

(transitivity)

A partially ordered set is any pair (L, v) where L is a set and v is a partial order on L. There can be x and y in L such that x 6v y and y 6v x.

Grégoire Sutre


Data Flow Analysis

VTSA’08

70 / 286

Lower and Upper Bounds Consider a partially ordered set (L, v) and a subset X ⊆ L.

Greatest Lower Bound A lower bound of X is any b ∈ X such that b v x for all x ∈ X . A greatest lower bound of X is any glb ∈ X such that: 1

glb is a lower bound of X ,

2

glb w b for any lower bound b of X .

If X has a greatest lower bound, then it is unique and written

Grégoire Sutre


Data Flow Analysis

d

X.

VTSA’08

71 / 286

Lower and Upper Bounds Consider a partially ordered set (L, v) and a subset X ⊆ L.

Greatest Lower Bound A lower bound of X is any b ∈ X such that b v x for all x ∈ X . A greatest lower bound of X is any glb ∈ X such that: [. . . ] If X has a greatest lower bound, then it is unique and written

d

X.

Least Upper Bound An upper bound of X is any b ∈ X such that b w x for all x ∈ X . A least upper bound of X is any lub ∈ X such that: 1

lub is an upper bound of X ,

2

lub v b for any upper bound b of X .

If X has a least upper bound, then it is unique and written Grégoire Sutre


Data Flow Analysis

F

X.

VTSA’08

71 / 286

Lower and Upper Bounds: Examples (R, ≤) o Gn √ = 4 0, 2, 4

l1 n∈N = 0 2n

But {. . . , −2, −1, 0, 1, 2, . . .} has no upper bound and no lower bound.

(P({−1, 0, 1}), ⊆) {−1, 0, 1} {−1, 0} {−1}

{−1, 1} {0}

F

{{0}, {1}}

= {0, 1}

F

{{−1}, {0, 1}}

= {−1, 0, 1}

d

{{−1, 0}, {0, 1}} = {0}

{0, 1} {1}

∅ Grégoire Sutre


Data Flow Analysis

VTSA’08

72 / 286

Lower and Upper Bounds: Examples (R, ≤) o Gn √ = 4 0, 2, 4

l1 n∈N = 0 2n

But {. . . , −2, −1, 0, 1, 2, . . .} has no upper bound and no lower bound.

(P({−1, 0, 1}), ⊆) {−1, 0, 1} {−1, 0} {−1}

{−1, 1} {0}

F

{{0}, {1}}

= {0, 1}

F

{{−1}, {0, 1}}

= {−1, 0, 1}

d

{{−1, 0}, {0, 1}} = {0}

{0, 1} {1}

∅ Grégoire Sutre


Data Flow Analysis

VTSA’08

72 / 286

Complete Lattice Definition A lattice is any partially ordered set (L, v) where every finite subset X ⊆ L has a greatest lower bound and a least upper bound.

Definition A complete lattice is any partially ordered set (L, v) where every subset X ⊆ L has a greatest lower bound and a least upper bound. The least element ⊥ and greatest element > are defined by: l G G l ⊥ = L = ∅ > = L = ∅

Example (R, ≤) is a lattice, but it is not a complete lattice. Grégoire Sutre


Data Flow Analysis

VTSA’08

73 / 286





Data Flow Analysis

VTSA’08

73 / 286





Data Flow Analysis

VTSA’08

73 / 286

Fixpoints Let f : L → L be a function on a partially ordered set (L, v).

Definition A fixpoint of f is any x ∈ L such that f (x) = x.

Definition A least fixpoint of f is any lfp ∈ X such that: 1

lfp is a fixpoint of f ,

2

lfp v x for any fixpoint x of f .

If f has a least fixpoint, then it is unique and written lfp(f ).

Definition A greatest fixpoint of f is any gfp ∈ X such that: 1

gfp is a fixpoint of f , gfp w x for any fixpoint x of f . Software Verification

2 Grégoire Sutre

Data Flow Analysis

VTSA’08

74 / 286



Definition A least fixpoint of f is any lfp ∈ X such that: 1

lfp is a fixpoint of f ,

2

lfp v x for any fixpoint x of f .

If f has a least fixpoint, then it is unique and written lfp(f ).


gfp is a fixpoint of f , gfp w x for any fixpoint x of f . Software Verification

2 Grégoire Sutre

Data Flow Analysis

VTSA’08

74 / 286



Definition A least fixpoint of f is any lfp ∈ X such that: [. . . ] If f has a least fixpoint, then it is unique and written lfp(f ).


gfp is a fixpoint of f ,

2

gfp w x for any fixpoint x of f .

If f has a greatest fixpoint, then it is unique and written gfp(f ). Grégoire Sutre


Data Flow Analysis

VTSA’08

74 / 286

Knaster-Tarski Fixpoint Theorem A function f : L → L on a partially ordered set (L, v) is monotonic if for all x, y ∈ L: x v y =⇒ f (x) v f (y )

Theorem Every monotonic function f on a complete lattice (L, v) has a least fixpoint lfp(f ) and a greatest fixpoint gfp(f ). Moreover: l lfp(f ) = {x ∈ L | f (x) v x} gfp(f ) =

Grégoire Sutre

G


{x ∈ L | f (x) w x}

Data Flow Analysis

VTSA’08

75 / 286

Order Duality If (L, v) is a partially ordered set then so is (L, w). If (L, v) is a complete lattice then so is (L, w). F d ⊥(L,w) = >(L,v) (L,v) (L,w) = F

(L,w)

=

d

(L,v)

>(L,w) = ⊥(L,v)

For any monotonic function f : L → L on a complete lattice (L, v), lfp(L,v) (f ) = gfp(L,w) (f ) gfp(L,v) (f ) = lfp(L,w) (f ) We shall focus on least fixpoints. Grégoire Sutre


Data Flow Analysis

VTSA’08

76 / 286

Order Duality If (L, v) is a partially ordered set then so is (L, w). If (L, v) is a complete lattice then so is (L, w). F d ⊥(L,w) = >(L,v) (L,v) (L,w) = F

(L,w)

=

d

(L,v)

>(L,w) = ⊥(L,v)

For any monotonic function f : L → L on a complete lattice (L, v), lfp(L,v) (f ) = gfp(L,w) (f ) gfp(L,v) (f ) = lfp(L,w) (f ) We shall focus on least fixpoints. Grégoire Sutre


Data Flow Analysis

VTSA’08

76 / 286

Ascending Chain Condition An ascending chain in a partially ordered set (L, v) is any infinite sequence x0 , x1 , . . . of elements of L satisfying xi v xi+1 for all i ∈ N. A partially ordered set (L, v) satisfies the ascending chain condition if every ascending chain x0 v x1 v · · · of elements of L is eventually stationary.

Examples (R, ≤) does not satisfy the ascending chain condition. (N, ≥) satisfies the ascending chain condition.

Grégoire Sutre


Data Flow Analysis

VTSA’08

77 / 286

Ascending Chain Condition An ascending chain in a partially ordered set (L, v) is any infinite sequence x0 , x1 , . . . of elements of L satisfying xi v xi+1 for all i ∈ N. A partially ordered set (L, v) satisfies the ascending chain condition if every ascending chain x0 v x1 v · · · of elements of L is eventually stationary.

Examples (R, ≤) does not satisfy the ascending chain condition. (N, ≥) satisfies the ascending chain condition.

Grégoire Sutre


Data Flow Analysis

VTSA’08

77 / 286

Kleene Iteration Consider a partially ordered set (L, v) and f : L → L monotonic. The Kleene iteration f i (⊥) i∈N is an ascending chain: ⊥ v f (⊥) v · · · v f i (⊥) v f i+1 (⊥) v · · · For every k ∈ N, if f k (⊥) = f k +1 (⊥) then f k (⊥) is the least fixpoint of f . LFP(f : L → L) x ← ⊥ repeat t ← x x ← f(x) until t = x return x

Grégoire Sutre

Correction and termination 1

For every monotonic f, if LFP(f) terminates then it returns lfp(f ).

2

If L satisfies the ascending chain condition then LFP(f) always terminates (on monotonic f).


Data Flow Analysis

VTSA’08

78 / 286

Kleene Iteration Consider a partially ordered set (L, v) and f : L → L monotonic. The Kleene iteration f i (⊥) i∈N is an ascending chain: ⊥ v f (⊥) v · · · v f i (⊥) v f i+1 (⊥) v · · · For every k ∈ N, if f k (⊥) = f k +1 (⊥) then f k (⊥) is the least fixpoint of f . LFP(f : L → L) x ← ⊥ repeat t ← x x ← f(x) until t = x return x

Grégoire Sutre

Correction and termination 1

For every monotonic f, if LFP(f) terminates then it returns lfp(f ).

2

If L satisfies the ascending chain condition then LFP(f) always terminates (on monotonic f).


Data Flow Analysis

VTSA’08

78 / 286

Constructing Complete Lattices: Power Set

For any set S, the pair (P(S), v) is a complete lattice, where v = ⊆. d F , , ⊥ and > satisfy: d

=

T

⊥ = ∅

F

=

S

> = S

If S is finite then (P(S), v) satisfies the ascending chain condition.

Grégoire Sutre


Data Flow Analysis

VTSA’08

79 / 286

Constructing Complete Lattices: Functions For any set S and complete lattice (L, v), the pair (S → L, v) is a complete lattice, where v is defined by: f vg

if

f (x) v g(x) for all x ∈ S

d F , , ⊥ and > satisfy: d d X = λ x . {f (x) | f ∈ X } F

X

= λx .

F

{f (x) | f ∈ X }

⊥ = λx .⊥ > = λx .>

If S is finite and (L, v) satisfies the ascending chain condition then (S → L, v) satisfies the ascending chain condition.

Grégoire Sutre


Data Flow Analysis

VTSA’08

80 / 286

Outline — Data Flow Analysis

5

Classical Data Flow Analyses

6

Basic Lattice Theory

7

Monotone Data Flow Analysis Frameworks

Grégoire Sutre


Data Flow Analysis

VTSA’08

81 / 286

Common Form of Data Flow Equations (Recall) Domain D of data flow “information” sets of variables, sets of expressions, valuations, . . .


Dq

=

! f Dq 0




Data Flow Analysis

VTSA’08

82 / 286

Monotone Frameworks Monotone Framework Complete lattice (L, v) of data flow facts Set F of monotonic transfer functions f : L → L Partial order v compares the precision of data flow facts: φ v ψ means that φ is more precise than ψ. F X is the most precise fact consistent with all facts φ ∈ X .

Conservative Approximation φ v ψ means that ψ soundly approximates φ. If φ v ψ then it is sound, but less precise, to replace φ by ψ. Grégoire Sutre


Data Flow Analysis

VTSA’08

83 / 286




Data Flow Analysis

VTSA’08

83 / 286




Data Flow Analysis

VTSA’08

83 / 286

Data Flow Facts: Example for Live Variables Analysis Semantic Definition of Liveness A variable x is live at location q if there exists an execution path starting from q where x is used before it is modified. Consider a control flow automaton with variables X = {x, y, z}. Complete lattice (L, v) of data flow facts: (P(X), ⊆) The fact {x, z} means: i.e.

the variables that are live are among {x, z}. the variable y is not live.

The fact {x} is more precise than {x, z}, but incomparable with {y}. The fact {x, z} soundly approximates the fact {x}.

Grégoire Sutre


Data Flow Analysis

VTSA’08

84 / 286

Data Flow Instances Data Flow Instance Monotone framework h(L, v), Fi Control flow automaton hQ, qin , qout , X, →i Transfer mapping f : Op → F Initial data flow value ı ∈ L Notation for transfer mapping: fop instead of f (op) Two possible directions for data flow analysis: forward and backward Transfer functions fop must be defined in accordance with the direction of the analysis. Grégoire Sutre


Data Flow Analysis

VTSA’08

85 / 286

Data Flow Instances Data Flow Instance Monotone framework h(L, v), Fi Control flow automaton hQ, qin , qout , X, →i Transfer mapping f : Op → F Initial data flow value ı ∈ L Notation for transfer mapping: fop instead of f (op) Two possible directions for data flow analysis: forward and backward Transfer functions fop must be defined in accordance with the direction of the analysis. Grégoire Sutre


Data Flow Analysis

VTSA’08

85 / 286

Data Flow Equations Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i. System of equations: variables Aq for q ∈ Q, with Aq ∈ L

Forward Analysis G

Aq = Iq t

fop (Aq 0 )

Iq

( ı if q = qin = ⊥ otherwise

Iq

( ı if q = qout = ⊥ otherwise

op

q 0 −→q

Backward Analysis Aq = Iq t

G

fop (Aq 0 )

op

q −→q 0

Grégoire Sutre


Data Flow Analysis

VTSA’08

86 / 286

Data Flow Equations Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i. System of equations: variables Aq for q ∈ Q, with Aq ∈ L

Forward Analysis G

Aq = Iq t

fop (Aq 0 )

Iq

( ı if q = qin = ⊥ otherwise

Iq

( ı if q = qout = ⊥ otherwise

op

q 0 −→q

Backward Analysis Aq = Iq t

G

fop (Aq 0 )

op

q −→q 0

Grégoire Sutre


Data Flow Analysis

VTSA’08

86 / 286

Minimal Fixpoint (MFP) Solution The system of data flow equations may have several solutions. . . We are interested in the “least solution” to the data flow equations. Complete lattice (L, v) extended to (Q → L, v) −−→ The forward minimal fixpoint solution MFP of the data flow instance → − is the least fixpoint of the monotonic function ∆ on (Q → L):

− → ∆(a) = λ q .

 ı t          

Grégoire Sutre

G

fop (a(q 0 )) if q = qin

op

q 0 −→q

G

fop (a(q 0 )) otherwise

op

q 0 −→q


Data Flow Analysis

VTSA’08

87 / 286

Minimal Fixpoint (MFP) Solution The system of data flow equations may have several solutions. . . We are interested in the “least solution” to the data flow equations. Complete lattice (L, v) extended to (Q → L, v) −−→ The forward minimal fixpoint solution MFP of the data flow instance → − is the least fixpoint of the monotonic function ∆ on (Q → L):

− → ∆(a) = λ q .

 ı t          

Grégoire Sutre

G

fop (a(q 0 )) if q = qin

op

q 0 −→q

G

fop (a(q 0 )) otherwise

op

q 0 −→q


Data Flow Analysis

VTSA’08

87 / 286

Minimal Fixpoint (MFP) Solution The system of data flow equations may have several solutions. . . We are interested in the “least solution” to the data flow equations. Complete lattice (L, v) extended to (Q → L, v) ←−− The backward minimal fixpoint solution MFP of the data flow instance ← − is the least fixpoint of the monotonic function ∆ on (Q → L): G  ı t fop (a(q 0 )) if q = qout     op  q −→q 0 ← − ∆(a) = λ q . G   fop (a(q 0 )) otherwise    op q −→q 0 Grégoire Sutre


Data Flow Analysis

VTSA’08

87 / 286

Constraint-Based Formulation Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i. Constraint system: variables Aq for q ∈ Q, with Aq ∈ L

Forward Analysis −−−→ (CS)

( Aqin w ı Aq 0

op

w fop (Aq ) for each q −→ q 0

By Knaster-Tarski Fixpoint Theorem, −−→ MFP

=

l n −−−→o a ∈ Q → L a |= (CS)

−−−→ −−→ Any solution to (CS) is a sound approximation of MFP. Grégoire Sutre


Data Flow Analysis

VTSA’08

88 / 286

Constraint-Based Formulation Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i. Constraint system: variables Aq for q ∈ Q, with Aq ∈ L

Backward Analysis ←−−− (CS)

( Aqout w ı Aq 0

op

w fop (Aq ) for each q 0 −→ q

By Knaster-Tarski Fixpoint Theorem, ←−− MFP

=

l n ←−−−o a ∈ Q → L a |= (CS)

←−−− ←−− Any solution to (CS) is a sound approximation of MFP. Grégoire Sutre


Data Flow Analysis

VTSA’08

88 / 286

Live Variables Analysis (Revisited) Control Flow Automaton: hQ, qin , qout , X, →i

Monotone Framework Complete lattice (L, v) of data flow facts: (P(X), ⊆) Set F of monotonic transfer functions: F = {λ φ . gen ∪ (φ \ kill) | gen, kill ∈ L}

Data Flow Instance Initial data flow value: ∅ Transfer mapping: fop (φ) = Genop ∪ (φ \ Killop ) Backward analysis Grégoire Sutre


Data Flow Analysis

VTSA’08

89 / 286

Available Expressions Analysis (Revisited) Control Flow Automaton: hQ, qin , qout , X, →i

Monotone Framework Complete lattice (L, v) of data flow facts: (P(SubExp(→)), ⊇) Set F of monotonic transfer functions: F = {λ φ . gen ∪ (φ \ kill) | gen, kill ∈ L}

Data Flow Instance Initial data flow value: ∅ Transfer mapping: fop (φ) = Genop ∪ (φ \ Killop ) Forward analysis Grégoire Sutre


Data Flow Analysis

VTSA’08

90 / 286

Constant Propagation Analysis (Revisited) Control Flow Automaton: hQ, qin , qout , X, →i

Constant Propagation Lattice for a Single Variable (R ∪ {⊥, >}, v)

>

φ ···

−2

−1

0

1

2

···

⊥

> r ∈R ⊥

Meaning

R {r } ∅

Monotone Framework

Complete lattice (L, v) of data flow facts: (X → (R ∪ {⊥, >}), v) Set F defined as the set of all monotonic transfer functions on L.

Grégoire Sutre


Data Flow Analysis

VTSA’08

91 / 286

Constant Propagation Analysis (Revisited) Control Flow Automaton: hQ, qin , qout , X, →i

Monotone Framework

Complete lattice (L, v) of data flow facts: (X → (R ∪ {⊥, >}), v) Set F defined as the set of all monotonic transfer functions on L.

Data Flow Instance Initial data flow value: > Transfer mapping: ( φ(y ) if y = 6 x fx:=e (φ) = λ y . JeKφ if y = x

fg (φ) = φ

Forward analysis Grégoire Sutre


Data Flow Analysis

VTSA’08

92 / 286

Constant Propagation Analysis (Revisited) Extension of JeK to valuations in X → (R ∪ {⊥, >})

For r ∈ R ∪ {>} >+r >−r >×r

= r +> = > = r −> = > = r ×> = >

For r ∈ R ∪ {⊥, >} ⊥+r ⊥−r ⊥×r

Grégoire Sutre

= r +⊥ = ⊥ = r −⊥ = ⊥ = r ×⊥ = ⊥


Expressions: JcKv JxKv

JeKv

= c

[c ∈ Q]

= v (x) [x ∈ X]

Je1 + e2 Kv

= Je1 Kv + Je2 Kv

Je1 * e2 Kv

= Je1 Kv × Je2 Kv

Je1 - e2 Kv

Data Flow Analysis

= Je1 Kv − Je2 Kv

VTSA’08

93 / 286

Constant Propagation Analysis (Revisited) Extension of JeK to valuations in X → (R ∪ {⊥, >})

For r ∈ R ∪ {>} >+r >−r >×r

= r +> = > = r −> = > = r ×> = >

For r ∈ R ∪ {⊥, >} ⊥+r ⊥−r ⊥×r

Grégoire Sutre

= r +⊥ = ⊥ = r −⊥ = ⊥ = r ×⊥ = ⊥



JeKv

= c

[c ∈ Q]

= v (x) [x ∈ X]

Je1 + e2 Kv

= Je1 Kv + Je2 Kv

Je1 * e2 Kv

= Je1 Kv × Je2 Kv

Je1 - e2 Kv

Data Flow Analysis

= Je1 Kv − Je2 Kv

VTSA’08

93 / 286

(Forward) MFP Computation by Kleene Iteration Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i.

a ← λq.⊥ repeat b ← a → − a ← ∆(a) until b = a return a

foreach q ∈ Q a[q] ← ⊥ a[qin ] ← ı repeat foreach q ∈ Q b[q] ← a[q] foreach q ∈ Q G a[q] ← fop (b[q 0 ])

Correction and termination 1 2

−−→ Returns MFP when it terminates

op

q 0 −→q

until (∀ q ∈ Q · b[q] = a[q]) return a

Always terminates when (L, v) satisfies the ascending chain condition

Grégoire Sutre


Data Flow Analysis

VTSA’08

94 / 286





−−→ Returns MFP when it terminates

op

q 0 −→q


Always terminates when (L, v) satisfies the ascending chain condition

Grégoire Sutre


Data Flow Analysis

VTSA’08

94 / 286





−−→ Returns MFP when it terminates Always terminates when (L, v) satisfies the ascending chain condition

Grégoire Sutre


op

q 0 −→q


We can improve! Data Flow Analysis

VTSA’08

94 / 286

(Forward) MFP Computation by Round-Robin Iteration Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i.

foreach q ∈ Q a[q] ← ⊥ a[qin ] ← ı do change ← false op foreach q −→ q 0 new ← fop (a[q]) if new 6v a[q 0 ] a[q 0 ] ← a[q 0 ] t new change ← true while change return a

Grégoire Sutre


The foreach loop iterates over transitions in →. Propagation of facts benefits from previous propagations records whether there was a change Correct and always faster than Kleene iteration Data Flow Analysis

VTSA’08

95 / 286

(Forward) MFP Computation by Round-Robin Iteration Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i.

foreach q ∈ Q a[q] ← ⊥ a[qin ] ← ı do change ← false op foreach q −→ q 0 new ← fop (a[q]) if new 6v a[q 0 ] a[q 0 ] ← a[q 0 ] t new change ← true while change return a

Grégoire Sutre


The foreach loop iterates over transitions in →. Propagation of facts benefits from previous propagations records whether there was a change Correct and always faster than Kleene iteration Data Flow Analysis

VTSA’08

95 / 286

(Forward) MFP Computation by Worklist Iteration Vs Round-Robin

wl ← nil op foreach q 0 −→ q wl ← cons((q, op, q 0 ), wl) foreach q ∈ Q a[q] ← ⊥ a[qin ] ← ı while wl 6= nil (q, op, q 0 ) ← head(wl) wl ← tail(wl) new ← fop (a[q]) if new 6v a[q 0 ] a[q 0 ] ← a[q] t new

, Less computations / Overhead

Worklist structures LIFO FIFO Set ...

0 0 op

foreach q −−→ q 00 wl ← cons((q 0 , op0 , q 00 ), wl) return a Grégoire Sutre


Data Flow Analysis

VTSA’08

96 / 286

(Forward) MFP Computation by Worklist Iteration Vs Round-Robin

wl ← nil op foreach q 0 −→ q wl ← cons((q, op, q 0 ), wl) foreach q ∈ Q a[q] ← ⊥ a[qin ] ← ı while wl 6= nil (q, op, q 0 ) ← head(wl) wl ← tail(wl) new ← fop (a[q]) if new 6v a[q 0 ] a[q 0 ] ← a[q] t new

, Less computations / Overhead

Worklist structures LIFO FIFO Set ...

0 0 op

foreach q −−→ q 00 wl ← cons((q 0 , op0 , q 00 ), wl) return a Grégoire Sutre


Data Flow Analysis

VTSA’08

96 / 286

Optimization of MFP Computation with SCCs

1

Decompose control flow automaton into strongly connected components

2

Transitions between SCCs induce a partial order between SCCs

3

Compute the MFP solution component after component, following the partial order between SCCs

This optimization often pays off in practice Further optimizations are possible. . .

Grégoire Sutre


Data Flow Analysis

VTSA’08

97 / 286

Optimization of MFP Computation with SCCs

1

Decompose control flow automaton into strongly connected components

2

Transitions between SCCs induce a partial order between SCCs

3

Compute the MFP solution component after component, following the partial order between SCCs

This optimization often pays off in practice Further optimizations are possible. . .

Grégoire Sutre


Data Flow Analysis

VTSA’08

97 / 286

Loss of Precision with the MFP Solution

x := 1

q1

q2 y := 2

x := 2 q3

q4

y := 1

z := x+y q5

At q5 , we have z = 3

Grégoire Sutre


Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > ⊥ ⊥ ⊥ ⊥

y > ⊥ ⊥ ⊥ ⊥

z > ⊥ ⊥ ⊥ ⊥

q5

Loss of Precision At q5 , we have z = 3

Grégoire Sutre

F Cause: application of at q4 to merge data flow information


Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 ⊥ ⊥ ⊥

y > > ⊥ ⊥ ⊥

z > > ⊥ ⊥ ⊥

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 ⊥ ⊥ ⊥

y > > ⊥ ⊥ ⊥

z > > ⊥ ⊥ ⊥

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 ⊥ ⊥

y > > > ⊥ ⊥

z > > > ⊥ ⊥

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 ⊥ ⊥

y > > > ⊥ ⊥

z > > > ⊥ ⊥

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 1 ⊥

y > > > 2 ⊥

z > > > > ⊥

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 1 ⊥

y > > > 2 ⊥

z > > > > ⊥

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 1t2 ⊥

y > > > 2t1 ⊥

z > > > > ⊥

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 > ⊥

y > > > > ⊥

z > > > > ⊥

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 > >

y > > > > >

z > > > > >

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 > >

y > > > > >

z > > > > >

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286


x := 1

q1

q2 y := 2

x := 2

q1 q2 q3 q4 q5

q3 q4

y := 1

z := x+y

x > 1 2 > >

y > > > > >

z > > > > >

q5


Grégoire Sutre



Data Flow Analysis

VTSA’08

98 / 286

Alternative Approach for Better Precision Control Paths from q1 to q5 x := 1

q1

q2 y := 2

x := 2 q3

q4

y := 1

q1 x := 1 q2 y := 2

z := x+y

q4 q5

z := x+y q5

q1 x := 2 q3 y := 1 q4 z := x+y q5


Grégoire Sutre


Data Flow Analysis

VTSA’08

99 / 286


q1

q2 y := 2

x := 2

(>, >, >) q1 x := 1

q3 q4

y := 1

(1, >, >)

q2

y := 2

z := x+y

(1, 2, >) q5

q4

z := x+y (1, 2, 3)

q5

q1 x := 2 q3 y := 1 q4 z := x+y q5


Grégoire Sutre


Data Flow Analysis

VTSA’08

99 / 286


q1

q2 y := 2

x := 2

(>, >, >) q1 x := 1

q3 q4

y := 1

(1, >, >)

q2

y := 2

z := x+y

(1, 2, >) q5

q4

z := x+y (1, 2, 3)

q5

q1 (>, >, >) x := 2 q3

(2, >, >)

y := 1 q4

(2, 1, >)

z := x+y q5

(2, 1, 3)


Grégoire Sutre


Data Flow Analysis

VTSA’08

99 / 286


q1

q2 y := 2

x := 2

(>, >, >) q1 x := 1

q3 q4

y := 1

q1 (>, >, >)

(1, >, >)

x := 2

q2

q3

y := 2

z := x+y

(1, 2, >) q5

y := 1

q4

q4

z := x+y (1, 2, 3)

(2, >, >)

(2, 1, >)

z := x+y

q5

q5

(2, 1, 3)

F At q5 , we have z = 3

Grégoire Sutre


= (>, >, 3)

Data Flow Analysis

VTSA’08

99 / 286

Meet Over All Paths (MOP) Solution Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i.

Forward Meet Over All Paths Solution o G n −−−→ op0 opk MOP = λ q . fopk ◦ · · · ◦ fop0 (ı) qin −−→ q1 · · · qk −−→ q

Backward Meet Over All Paths Solution o G n ←−−− opk op0 q1 · · · qk −−→ qout fop0 ◦ · · · ◦ fopk (ı) q −−→ MOP = λ q .

More precise than MFP −−−→ −−→ MOP v MFP ←−−− ←−− MOP v MFP Grégoire Sutre


Not Computable in General −−−→ ? MOP(q) = 1 is undecidable for constant propagation Data Flow Analysis

VTSA’08

100 / 286

Meet Over All Paths (MOP) Solution Consider a data flow instance h (L, v), F, Q, qin , qout , X, →, f , ı i.

Forward Meet Over All Paths Solution o G n −−−→ op0 opk MOP = λ q . fopk ◦ · · · ◦ fop0 (ı) qin −−→ q1 · · · qk −−→ q

Backward Meet Over All Paths Solution o G n ←−−− opk op0 q1 · · · qk −−→ qout fop0 ◦ · · · ◦ fopk (ı) q −−→ MOP = λ q .

More precise than MFP −−−→ −−→ MOP v MFP ←−−− ←−− MOP v MFP Grégoire Sutre


Not Computable in General −−−→ ? MOP(q) = 1 is undecidable for constant propagation Data Flow Analysis

VTSA’08

100 / 286

MOP = MFP in Distributive Frameworks A monotone framework h (L, v), F i is distributive if every f ∈ F is completely additive: F F f ( X) = {f (φ) | φ ∈ X } (for all X ⊆ L)

Theorem For any data flow instance over a distributive monotone framework, −−−→ −−→ MOP = MFP ←−−− ←−− MOP = MFP

Intuition F In a distributive framework,applying “early” does not lose precision: fop5 fop2 (φ) t fop3 (ψ) = fop5 ◦ fop2 (φ) t fop5 ◦ fop3 (ψ) Grégoire Sutre


Data Flow Analysis

VTSA’08

101 / 286

MOP = MFP in Distributive Frameworks A monotone framework h (L, v), F i is distributive if every f ∈ F is completely additive: F F f ( X) = {f (φ) | φ ∈ X } (for all X ⊆ L)

Theorem For any data flow instance over a distributive monotone framework, −−−→ −−→ MOP = MFP ←−−− ←−− MOP = MFP

Intuition F In a distributive framework,applying “early” does not lose precision: fop5 fop2 (φ) t fop3 (ψ) = fop5 ◦ fop2 (φ) t fop5 ◦ fop3 (ψ) Grégoire Sutre


Data Flow Analysis

VTSA’08

101 / 286

Examples of Distributive Monotone Frameworks Gen / Kill Monotone Frameworks Complete lattice (L, v) of data flow facts: L = P(S) for some set S

v is ⊆ or ⊇

Set F of monotonic transfer functions: F = {λ φ . gen ∪ (φ \ kill) | gen, kill ∈ L} All gen / kill monotone frameworks are distributive

Examples Live Variables

Uninitialized Variables

Available Expressions

...

Grégoire Sutre


Data Flow Analysis

VTSA’08

102 / 286

Sign Analysis: Monotone Framework Control Flow Automaton: hQ, qin , qout , X, →i

(Simplified) Sign Lattice for a Single Variable: (Sign, v) φ

>

−

+

0

⊥

Meaning

R > − {r ∈ R | r < 0} + {r ∈ R | r > 0} 0 {0} ⊥ ∅

Monotone Framework Complete lattice (L, v) of data flow facts: (X → Sign, v) Set F defined as the set of all monotonic transfer functions on L. Grégoire Sutre


Data Flow Analysis

VTSA’08

103 / 286

Sign Analysis: Data Flow Instance Control Flow Automaton: hQ, qin , qout , X, →i

Monotone Framework Complete lattice (L, v) of data flow facts: (X → Sign, v) Set F defined as the set of all monotonic transfer functions on L.

Data Flow Instance Initial data flow value: > Transfer mapping: ( φ(y ) if y = 6 x fx:=e (φ) = λ y . JeKφ if y = x

fg (φ) = φ

Forward analysis Grégoire Sutre


Data Flow Analysis

VTSA’08

104 / 286

Sign Analysis: Transfer Mapping Need to define JeK for valuations v in X → {−, 0, +, ⊥, >}


Je1 + e2 Kv

Je1 - e2 Kv

Je1 * e2 Kv

“Abstract” Addition

JeKv

= sign(c) [c ∈ Q] = v (x)

[x ∈ X]

= Je1 Kv ⊕ Je2 Kv

= Je1 Kv Je2 Kv

= Je1 Kv ⊗ Je2 Kv

  − if c < 0 sign(c) = 0 if c = 0   + if c > 0

Grégoire Sutre


⊕

⊥ −

0

+ >

⊥ − 0 + >

⊥ ⊥ ⊥ ⊥ ⊥

⊥ − 0 + >

⊥ > + + >

⊥ − − > >

⊥ > > > >

Tables also required for: “abstract” subtraction “abstract” multiplication Data Flow Analysis

VTSA’08

105 / 286



Je1 + e2 Kv

Je1 - e2 Kv

Je1 * e2 Kv

“Abstract” Addition

JeKv

= sign(c) [c ∈ Q] = v (x)

[x ∈ X]

= Je1 Kv ⊕ Je2 Kv

= Je1 Kv Je2 Kv

= Je1 Kv ⊗ Je2 Kv

  − if c < 0 sign(c) = 0 if c = 0   + if c > 0

Grégoire Sutre


⊕

⊥ −

0

+ >

⊥ − 0 + >

⊥ ⊥ ⊥ ⊥ ⊥

⊥ − 0 + >

⊥ > + + >

⊥ − − > >

⊥ > > > >


VTSA’08

105 / 286



Je1 + e2 Kv

Je1 - e2 Kv

Je1 * e2 Kv

= = = =

Are

the “Abstract” Addition se⊕ ⊥ − 0 + > sign(c) [c ∈ Q] ta v (x) [x ∈ X] ⊥ ⊥ble ⊥ ⊥ ⊥ ⊥ s −c > > − ⊥ − Je K ⊕ Je K or 0 ⊥ − 0 + re >c Je K Je K + ⊥ > + + > t? JeKv

1 v

2 v

1 v

2 v

= Je1 Kv ⊗ Je2 Kv

  − if c < 0 sign(c) = 0 if c = 0   + if c > 0

Grégoire Sutre


>

⊥ > > > >


VTSA’08

105 / 286


Are

the “Abstract” Addition se⊕ ⊥ − 0 + > JcK = sign(c) [c ∈ Q] ta JxK = v (x) [x ∈ X] ⊥ ⊥ble ⊥ ⊥ ⊥ ⊥ s −c > > − ⊥ − + e K = Je K ⊕ Je K orr 0 ⊥ − 0 + e >c - e K Does = Jethis K data Je K flow instance + ⊥ > + + > t?

Expressions:

JeKv

v

v

Je1 Je1

2 v

1 v

2 v

2 v

1 v

2 v

Je1 * e2 Kreally perform v = Je 1 Kv ⊗ Je2 Kv sign

analysis? > ⊥ >

> > >

Is correct? − ifanalysis c 0

Grégoire Sutre


“abstract” multiplication Data Flow Analysis

VTSA’08

105 / 286

What About Correctness of Data Flow Analyses? Framework Desired Analysis

(L, v) F ı∈L f : Op → F Transfer

Solution MFP MOP

hQ, qin , qout , X, →i Program

Grégoire Sutre


Data Flow Analysis

VTSA’08

106 / 286


Ideal Solution

Grégoire Sutre

(L, v) F ı∈L f : Op → F Transfer

hQ, qin , X, →i

hQ, qin , qout , X, →i

Semantics

Program


Data Flow Analysis

Solution MFP MOP

VTSA’08

106 / 286


(L, v) F ı∈L f : Op → F

Ideal Solution

Transfer

hQ, qin , X, →i

hQ, qin , qout , X, →i

Semantics

Program

Solution MFP MOP

soundly approximates Grégoire Sutre


Data Flow Analysis

VTSA’08

106 / 286


(L, v) F ı∈L f : Op → F

sis

h

ac e r o of f

Ideal Solution

ect r r co

pro s nes

al hQ, qin , X, →i u n Ma Semantics

Transfer

ly ana

Solution MFP MOP

hQ, qin , qout , X, →i Program

soundly approximates Grégoire Sutre


Data Flow Analysis

VTSA’08

106 / 286

How to Systematically Ensure Correctness? Data flow facts have an intended meaning. The transfer mapping is designed according to this intended meaning. We need a formal link to relate data flow facts and transfer functions with the formal semantics.

Solution: Abstract Interpretation « This paper is devoted to the systematic and correct design of program analysis frameworks with respect to a formal semantics. » P. Cousot & R. Cousot. Systematic Design of Program Analysis Frameworks. Sixth Annual Symposium on Principles of Programming Languages, 1979.

Grégoire Sutre


Data Flow Analysis

VTSA’08

107 / 286

How to Systematically Ensure Correctness? Data flow facts have an intended meaning. The transfer mapping is designed according to this intended meaning. We need a formal link to relate data flow facts and transfer functions with the formal semantics.

Solution: Abstract Interpretation « This paper is devoted to the systematic and correct design of program analysis frameworks with respect to a formal semantics. » P. Cousot & R. Cousot. Systematic Design of Program Analysis Frameworks. Sixth Annual Symposium on Principles of Programming Languages, 1979.

Grégoire Sutre


Data Flow Analysis

VTSA’08

107 / 286