Principles of Program Analysis

Principles of Program Analysis
Flemming Nielson Hanne Riis Nielson

Chris Hankin
Principles
of Program Analysis
With 56 Figures and 51 Tables
~Springer
Flemming Nielson
Hanne Riis Nielson
The Technical University of Denmark
Informatics and Mathematical Modelling
Richard Petersens Plads, Bldg. 321
2800 Kongens Lyngby, Denmark
E-mail: {nielson, riis}@imm.dtu.dk
WWW: http://www.imm.dtu.dk/ -riis/PPA/ppa.html
Chris Hankin
Department of Computing
The Imperial College of Science, Technology, and Medicine
180 Queen's Gate, London SW7 2BZ, UK
E-mail: [email protected]
Cataloging-in-Publication data applied for

Die Deutsche Bibliothek- CIP-Einheitsaufnahme
Nielson, Flemming:
Principles of program analysis: with 51 tables/F. Nielson; H.R.
Nielson; C. Hankin. - Berlin; Heidelberg; New York; Barcelona;
Hong Kong; London; Milan; Paris; Singapore; Tokyo: Springer,
1999
ISBN 978-3-642-08474-4 ISBN 978-3-662-03811-6 (eBook)
DOI 10.1007/978-3-662-03811-6
ACM Computing Classification (1998): F.3.2, D.3, F.3, D.2
ISBN 978-3-642-08474-4 Springer Berlin Heidelberg New York
lst edition 1999. Corrected 2nd printing 2005
This work is subject to copyright. Ali rights are reserved, whether the whole or part of the material is concerned,
specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on
microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is
permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version,
and permission for use must always be obtained from Springer. Violations are liable for prosecution under the
German Copyright Law.
Springer is a part of Springer Science+ Business Media
springeronline.com
© Springer-Verlag Berlin Heidelberg 1999, 2005

Softcover re print of the hardcover 1st edition 2005
The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in
the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and
therefore free for general use.
Typesetting: Camera-ready by the authors

Cover design: Erich Kirchner, Heidelberg
Production: LE-TeX )elonek, Schmidt & V<ickler GbR, Leipzig
Printed on acid-free paper 45/3142/YL- 5 4 3 2 1 O
Preface
Aims of the book. Our motivation for writing this book is twofold.
One is that for quite some time we have lacked a textbook for our own courses
on program analysis; instead we have been forced to base the courses on
conference papers supplemented with the occasional journal paper or chapter
from a text book out of print. The other is the growing feeling that the
various subcommunities in the field often study similar problems without
being sufficiently aware of insights or developments generally known in other
subcommunities. The idea then emerged that perhaps a text book could be
written that both would be useful for advanced courses on program analysis
and that would help increase the awareness in the field about the many
similarities between the various approaches.
There is an important analogy to complexity theory here. Consider re-
searchers or students looking through the literature for a clever algorithm
or heuristics to solve a problem on graphs. They might come across papers
on clever algorithms or heuristics for solving problems on boolean formulae
and might dismiss them on the grounds that graphs and boolean formulae
surely are quite different things. Yet complexity theory tells us that this is
quite a mistaken point of view. The notions of log-space reduction between
problems and of NP-complete problems lead to realising that problems may
appear unrelated at first sight and nonetheless be so closely related that a
good algorithm or heuristics for one will give rise to a good algorithm or
heuristics for the other. We believe it to be a sad fact that students of
programming languages in general, and program analysis in particular, are
much too often allowed to get away with making similarly naive decisions
and arguments. Program analysis is stiH far from being able to precisely re-
late ingredients of different approaches to one another but we hope that this
book will help to bring this about. In fact, we hope to shock quite a number
of readers by convincing them that there are important similarities between
the approaches of their own work and other approaches deemed to be of no
relevance.
This book concentrates on what we believe to be the four main approaches to
program analysis: Data Flow Analysis; Constraint Based Analysis; Abstract
VI Preface
Interpretation; and Type and Effect Systems. For each approach we aim
at identifying and describing the important general principles, rather than
presenting a cook-book of techniques and language constructs, with a view
to how the principles scale up for more complex programming languages and
analyses.
As a consequence we have deliberately decided that this book should not
treat a number of interesting approaches, some of which are dear to the
heart of the authors, in order to be able to cover the four main approaches
to some depth; the approaches not covered include denotationally based pro-
gram analysis, projection analysis, and logical formulations based on Stone
dualities. For reasons of space, we have also had to omit material that would
have had a natural place in the book; this includes a deeper treatment of
set constraints, fast techniques for implementing type based analyses, single
static assignment form, a broader treatment of pointer analyses, and the in-
terplay between analysis and transformation and how to efficiently recompute
analysis information invalidated by the transformation.
How to read the book. The book is relatively self-contained although

the reader will benefit from previous exposure to discrete mathematics and
compilers. The main chapters are generally rigorous in the early parts where
the basic techniques are covered, but less so in the later parts where more
advanced techniques are covered.
Chapter 1 is intended to be read quickly. The purpose of the chapter is to
give an overview of the main approaches to program analysis, to stress the
approximate nature of program analysis, and to make it clear that seemingly
different approaches may yet have profound similarities. We recommend
reading through all of Chapter 1 even though the reader might want to spe-
cialise in only parts of the book.
Chapter 2 introduces Data Flow Analysis. Sections 2.1 to 2.4 cover the basic
techniques for intraprocedural analysis, including the Monotone Frameworks
as generalisations of the Bit Vector Frameworks, and a worklist algorithm
for computing the information efficiently. Section 2.2 covers more theoretical
properties (semantic correctness) and can be omitted on a first reading. The
presentation makes use of notions from lattice theory and for this we refer to
Appendix A.1, A.2 and parts of A.3. - Section 2.5 is a more advanced section
that gives an overview of interprocedural analysis including a treatment of call
string based methods and methods based on assumption sets; since Section
2.5 is used as a stepping stone to Chapter 3 we recommend to read at least
up to Subsection 2.5.2. Section 2.6 is an advanced section that illustrates
how the relatively simple techniques introduced so far can be combined to
develop a very complex shape analysis, but the material is not essential for
the remainder of the book.
Preface VII
Chapter 3 covers Constraint Based Analysis. The treatment makes a clear

distinction between determining the safety of an analysis result and how to
compute the best safe result; it also stresses the need to analyse open systems.
Sections 3.1, 3.3 and 3.4 cover the basic techniques; these include coinduction
which is likely to be new to most readers and we refer to the treatment in
Appendix B (building upon Tarski's theorem as covered in Appendix A.4).
Section 3.2 covers more theoretical properties (semantic correctness and the
existence of best solutions) and can be omitted on a first reading. - Sections
3.5 and 3.6 extend the development so as to link up with the treatment
of Data Flow Analysis. Section 3.5 shows how to incorporate Monotone
Frameworks (Section 2.3) and Section 3.6 shows how to add context in the
manner of caii strings and assumption sets (Section 2.5).
Chapter 4 covers Abstract Interpretation in a programming language inde-
pendent fashion in order to stress that it can be integrated both with Data
Flow Analysis and Constraint Based Analysis. Section 4.1 introduces some
of the key considerations and is used to motivate some of the technical def-
initions in later sections. Section 4.2 deals with the use of widening and
narrowing for approximating fixed points and Sections 4.3 deals with Galois
connections; this order of presentation has been chosen to stress the funda-
mental nature played by widenings but the sections are largely independent
of one another. - Sections 4.4 and 4.5 study how to build Galois connec-
tions in a systematic manner and how to use them for inducing approximate
analyses; the material is not essential for the remainder of the book.
Chapter 5 covers Type and Effect Systems which is an approach to program
analysis that is often viewed as having a quite different flavour from the ap-
proaches covered so far. Section 5.1 presents the basic approach (by linking
back to the Constraint Based Analyses studied in Chapter 3) and suffices for
getting an impression of the approach. Section 5.2 studies more theoretical
properties (semantic correctness) and Section 5.3 studies algorithmic issues
(soundness and completeness of a variation of algorithm W) and these sec-
tions can be omitted on a first reading. - Sections 5.4 and 5.5 gradually
introduce more and more advanced Type and Effect Systems.
Chapter 6 presents algorithms for Data Flow Analysis and Constraint Based
Analysis. The treatment concentrates on general techniques for solving sys-
tems of inequations. We emphasise the fact that, to a large extent, the same
set of techniques can be used for a number of different approaches to pro-
gram analysis. Section 6.1 presents a general worklist algorithm, where the
operations on the worklist constitute an abstract data type, and its correct-
ness and complexity is established. Section 6.2 organises the worklist so that
iteration takes place in reverse postorder and the Round Robin Algorithm is
obtained as a special case. Section 6.3 then further identifies strong compo-
nents and iterates through each strong component in reverse postorder before
considering the next.
VIII Preface
Appendices A and C review the concepts from partially ordered sets, graphs
and regular expressions that are used throughout the book. Appendix B is
more tutorial in nature since coinduction is likely to be a new concept for
most readers.
To help the reader when navigating through the book we provide a table of
contents, a list of tables, and a list of figures at the front of the book and an
index of the main concepts and an index of notation at the end of the book.
The index of notation is divided into three parts: first the mathematical
symbols (with an indication of where they take their parameters), then the
notation beginning with a greek letter, and finally the notation beginning
with a letter in the latin alphabet (regardless of the font used). The book
concludes with a bibliogmphy.
Our notation is mostly standard and is explained when introduced. However,
it may be helpful to point out that we will be using "iff" as an abbreviation
for "if and only if", that we will be using · · · [· · · ~ · · ·] to mean both syntactic
substitution as well as update of an environment or stare, and that we will
be writing · · · -tfin · · · for the set of finitary functions: these are the partial
functions with a finite domain. We also use Ă-notation for functions when it
improves the clarity of presentation: Ax. · · · x · · · stands for the unary function
f defined by f(x) = · · · x · · ·.
Most proofs and some technical lemmas and facts are in small print in order
to aid the reader in navigating through the book.
How to teach from the book. The book contains more material
than can be covered in a one semester course. The pace naturally depends
on the background of the students; we have taught the course at different
paces to students in their fourth year as well as to Ph.D.-students with a
variety of backgrounds. Below we summarise aur experiences on how many
lectures are needed for covering the various parts of the book; it supplements
the guide-lines presented above for how to read the book.
Two or three lectures should suffi.ce for covering all of Chapter 1 and possibly
some of the simpler concepts from Appendix A.1 and A.2.
Sections 2.1, 2.3 and 2.4 are likely to be central to any course dealing with
data flow analysis. Three to faur lectures should suffice for covering Sections
2.1 to 2.4 but five lectures may be needed if the students lack the necessary
background in operational semantics or lattice theory (Appendix A.1, A.2
and parts of A.3). - Sections 2.5 and 2.6 are more advanced. One or two
lectures suffi.ce for covering Section 2.5 but it is hard to pay justice to Section
2.6 in less than two lectures.
Faur or five lectures should suffi.ce for a complete treatment of both Chapter
3 and Appendix B; however, the concept of coinduction takes some time to
get used to and should be explained more than once.
Preface IX
Four or five lectures should suffice for a complete treatment of Chapter 4 as

well as Appendix A.4.
About four lectures should suffice for a complete treatment of Chapter 5.
Two lectures should suffice for Chapter 6 but three lectures may be needed
if large parts of Appendix C need tobe reviewed.
We have always covered the appendices as an integrated part of the other
chapters; indeed, some of the foundations for partial orders are introduced
gently in Chapter 1 and most of our students have had some prior exposure
to partial orders, graphs and regular expressions.
The book contains numerous exercises and severa! mini projects which are
small projects dealing with practica! or theoretical aspects of the develop-
ment. Many of the important links and analogies between the various chap-
ters are studied in the exercises and mini projects. Some of the harder exer-
cises are starred.
Acknowledgements. We should like to thank Reinhard Wilhelm for

his long and lasting interest in this project and for his many encouraging and
constructive remarks. We have also profited greatly from discussions with
Alan Mycroft, Mooly Sagiv and Helmut Seidl about their perspective on
selected parts of the manuscript. Many other colleagues have influenced the
writing of the book and we should like to thank them all; in particular Alex
Aiken, Torben Amtoft, Patrick Cousot, Laurie Hendren, Suresh Jagannathan,
Florian Martin, Barbara Ryder, Bernhard Steffen. We are grateful to Schloss
Dagstuhl for having hosted two key meetings: a one-week meeting among the
authors in March of 1997 (during which we discovered the soothing nature
of Vangelis' 1492) and our advanced course in November of 1998. Warm
thanks go to the many students attending the advanced course in Dagstuhl,
and to the many students in Aarhus, London, Saarbriicken and Tel Aviv that
have tested the book as it evolved ever so slowly. Finally, we should like to
thank Alfred Hofmann at Springer for a very satisfactory contract and Rene
Rydhof Hansen for his help in tuning the Ib'IEX commands.
Aarhus and London Flemming Nielson

August, 1999 Hanne Riis Nielson
Chris Hankin
Preface to the second printing. In this second printing we have

corrected all errors and shortcomings pointed out to us. We should like to
thank Torben Amtoft, John Tang Boyland, Jurriaan Hage and Mirko Luedde
as well as our students for their observations.
Official web page. Further information about the book is available at

the web page http://www.imm..dtu.dkrriis/PPA/ppa.html. Here we will
X Preface
provide information about availability of the book, a list of misprints (initially

empty), pointers to web based tools that can be used in conjunction with the
book, and transparencies and other supplementary material. Instructors are
encouraged to send us teaching material for inclusion on the web page.
Lyngby and London Flemming Nielson

October, 2004 Hanne Riis Nielson
Chris Hankin
Contents
1 Introduction 1
1.1 The Nature of Program Analysis 1
1.2 Setting the Scene o o 3
1.3 Data Flow Analysis o 5
1.301 The Equational Approach 5
1.302 The Constraint Based Approach 8
1.4 Constraint Based Analysis o 10
1.5 Abstract Interpretation 13
1.6 Type and Effect Systems o 17
1.601 Annotated Type Systems 18
1.602 Effect Systems 22
1.7 Algorithms o o o 25
1.8 Transformations 27
Concluding Remarks 29
Mini Projects 29
Exercises o o 31
2 Data Flow Analysis 35

201 Intraprocedural Analysis o o o ••••• 35
201.1 Available Expressions Analysis 39
201.2 Reaching Definitions Analysis o 43
201.3 Very Busy Expressions Analysis 46
201.4 Live Variables Analysis ••• o • 49
201.5 Derived Data Flow Information o 52
XII Contents
2.2 Theoretical Properties . . . . . . . . . . . 54

2.2.1 Structural Operational Semantics . 54
2.2.2 Correctness of Live Variables Analysis 60
2.3 Monotone Frameworks . 65
2.3.1 Basic Definitions 67
2.3.2 The Examples Revisited . 70
2.3.3 A Non-distributive Example. 72
2.4 Equation Solving . . . . . 74
2.4.1 The MFP Solution 74
2.4.2 The MOP Solution . 78
2.5 Interprocedural Analysis .. 82
2.5.2 Intraprocedural versus Interprocedural Analysis . 88
2.5.3 Making Context Explicit . 90
2.5.4 Call Strings as Context 95
2.5.5 Assumption Sets as Context . 99
2.5.6 Flow-Sensitivity versus Flow-Insensitivity 101
2.6 Shape Analysis •••••••••••••• o 104
2.6.2 Shape Graphs . 109
2.6.3 The Analysis 115
Mini Projects 132
Exercises .. 135
3 Constraint Based Analysis 141

3.1 Abstract 0-CFA Analysis 141
3.1.1 The Analysis ... 143
3.1.2 Well-definedness of the Analysis 150
3.2 Theoretical Properties . . . . . . . . . . 153
3.2.2 Semantic Correctness 158
3.2.3 Existence of Solutions 162
Contents XIII
3.2.4 Coinduction versus Induction 165

3.3 Syntax Directed 0-CFA Analysis .. 168
3.3.1 Syntax Directed Specification 169
3.3.2 Preservation of Solutions 171
3.4 Constraint Based 0-CFA Analysis . 173
3.4.1 Preservation of Solutions 175
3.4.2 Solving the Constraints 176
3.5 Adding Data Flow Analysis . . 182
3.5.1 Abstract Values as Powersets 182
3.5.2 Abstract Values as Complete Lattices 185
3.6 Adding Context Information . . . 189
3.6.1 Uniform k-CFA Analysis. 191
3.6.2 The Cartesian Product Algorithm 196
Mini Projects 202
Exercises .. 205
4 Abstract Interpretation 211

4.1 A Mundane Approach to Correctness. 211
4.1.1 Correctness Relations .. 214
4.1.2 Representation Functions 216
4.1.3 A Modest Generalisation 219
4.2 Approximation of Fixed Points 221
4.2.1 Widening Operators 224
4.2.2 Narrowing Operators . 230
4.3 Galois Connections . . . . . . 233
4.3.1 Properties of Galois Connections 239
4.3.2 Galois Insertions ......... 242
4.4 Systematic Design of Galois Connections . 246
4.4.1 Component-wise Combinations 249
4.4.2 Other Combinations 253
4.5 Induced Operations . . . . . 258
4.5.1 Inducing along the Abstraction Function . 258
XIV Contents
4.5.2 Application to Data Flow Analysis . . . . . 262

4.5.3 Inducing along the Concretisation Function 267
Mini Projects 274
Exercises .. 276
5 Type and Effect Systems 283

5.1 Control Flow Analysis . . . . . . . . 283
5.1.1 The Underlying Type System 284
5.1.2 The Analysis ... 287
5.2 Theoretical Properties .. 291
5.2.1 Natural Semantics 292
5.2.2 Semantic Correctness 294
5.3 Inference Algorithms . . . . . 300
5.3.1 An Algorithm for the Underlying Type System 300
5.3.2 An Algorithm for Control Flow Analysis . 306
5.3.3 Syntactic Soundness and Completeness 312
5.4 Effects . . . . . . . . . . . . 319
5.4.1 Side Effect Analysis 319
5.4.2 Exception Analysis . 325
5.4.3 Region Inference .. 330
5.5 Behaviours . . . . . . . . . 339
5.5.1 Communication Analysis 339
Mini Projects 353
Exercises .. 359
6 Algorithms 365
6.1 Worklist Algorithms . . . . . . . . . . . . . . 365
6.1.1 The Structure of Worklist Algorithms 368
6.1.2 Iterating in LIFO and FIFO. 372
6.2 Iterating in Reverse Postorder . . . . 374
Contents XV
6.2.1 The Round Robin Algorithm . 378

6.3 Iterating Through Strong Components 381
Mini Projects 387
Exercises .. 389
A Partially Ordered Sets 393

A.1 Basic Definitions . . •••• o ••• 393
A.2 Construction of Complete Lattices 397
A.3 Chains . . . . 398
A.4 Fixed Points 402
B Induction and Coinduction 405

B.1 Proof by Induction . . . . 405
B.2 Introducing Coinduction . 407
B.3 Proof by Coinduction 411
Concluding Remarks . . . . 415
c Graphs and Regular Expressions 417

C.1 Graphs and Forests . 417
C.2 Reverse Postorder . 421
C.3 Regular Expressions 426
Index of N otation 429
Index 433
Bibliography 439
List of Tables
1.1 Reaching Definitions information for the factorial program. 4

1.2 Reaching Definitions: annotated base types. . . . . 19
1.3 Reaching Definitions: annotated type constructors. 21
1.4 Call-tracking Analysis: Effect System. . . . 24
1.5 Chaotic Iteration for Reaching Definitions. . 26
1.6 Constant Folding transformation. . . . . . . 27
2.1 Available Expressions Analysis. 40

2.2 Reaching Definitions Analysis. 44
2.3 Very Busy Expressions Analysis. 47
2.4 Live Variables Analysis. . . . . . 50
2.5 Semantics of expressions in WHILE. . 55
2.6 The Structural Operational Semantics of WHILE. 56
2. 7 Constant Propagation Analysis. . . . . . . 73
2.8 Algorithm for solving data fl.ow equations. 75
2.9 Iteration steps of the worklist algorithm. . 76
2.10 The instrumented semantics of WHILE.. . 133
3.1 Abstract Control Flow Analysis (Subsections 3.1.1 and 3.1.2). 146
3.2 The Structural Operational Semantics of FuN (part 1). 155
3.3 The Structural Operational Semantics of FUN (part 2). 156
3.4 Abstract Control Flow Analysis for intermediate expressions. 158
3.5 Syntax directed Control Flow Analysis. . 170
3.6 Constraint based Control Flow Analysis. . 174
3. 7 Algorithm for solving constraints. . . . . . 178
XVIII List of Tables
308 Abstract values as powersetso o o o o 184

309 Abstract values as complete latticeso 188
3010 Uniform k-CFA analysiso o o o o 192
501 The Underlying Type Systemo o 285

502 Control Flow Analysiso o o o 288
503 Equality of Annotationso o o 290
5.4 Natural Semantics for FUNo 292
505 Algorithm WuL for the underlying type systemo 303
506 Unification of underlying typeso o o o o o o o 305
507 Unification of simple typeso o o o o o o o o o 307
508 Algorithm WcFA for Control Flow Analysiso 310
509 Side Effect Analysiso 322
5010 Exception Analysiso 328
5011 Natural Semantics for extended expressionso o 334
5012 Region Inference Analysis and Translation (part 1)0 o 337
5013 Region lnference Analysis and Translation (part 2)0 o 338
5014 The sequential semanticso o o o o o 341
5015 The concurrent semanticso o o o o o 343
5016 Communication Analysis (part 1)0 346
5o17 Communication Analysis (part 2)0 347
5018 Ordering on behaviourso o o o o o o 348
601 The Abstract Worklist Algorithmo 369

602 Iterating in last-in first-out order (LIFO)o 373
603 Iterating in reverse postordero o o o o o 376
6.4 The Round Robin Algorithmo o o o o o 379
605 Pseudocode for constraint numberingo 382
606 Iterating through strong componentso 384
Co1 The DFSF Algorithmo o o o o o o o o o 421

List of Figures
1.1 The nature of approximation: erring on the safe side. . 2

1.2 Flow graph for the factorial program. . 6
1.3 The adjunction (a,)'). . . . . . . . 15
2.1 Flow graph for the power program. 38

2.2 A schematic flow graph. . . . . . . 41
2.3 A schematic flow graph (in reverse). 48
2.4 Preservation of analysis result. 61
2.5 The correctness result for live. . 62
2.6 Instances for the four classical analyses. 70
2. 7 Flow graph for the Fibonacci program. . 85
2.8 Analysis of procedure call: the forward case. . 93
2.9 Analysis of procedure call: ignoring calling context. . 94
2.10 Analysis of procedure call: merging of context. 95
2.11 Procedure call graph for example program. 103
2.12 Reversal of a list of five elements. . . . . . . 106
2.13 Shape graphs corresponding to Figure 2.12. 112
2.14 Sharing information. . . . . . . . . . . . . . 113
2.15 The single shape graph in the extremal value L for the list
reversal program. . . . . . . . . . 115
2.16 The effect of [x: =nil]'. . . . . . . . . . . . . . 116
2.17 The effect of [x: =y]f when x"#y. . . . . . . . . . 118
2.18 The effect of [x:=y.seljf in Case 2 when x "IY·. 120
2.19 The effect of [x:=y.sel]l in a special case (part 1).. 123
2.20 The effect of [x: =y.sel]' in a special case (part 2). . 124
XX List of Figures
2.21 The effect of [x.sel: =niljf when #into(nu, H') :::;1. 126
2.22 The effect of [x.sel: =y]f when #into( ny, H') < 1. 127
2.23 du-and ud-chains. . . . . . . . . . . . . . . . . . . 132
3.1 Pictorial illustration of the clauses [let] and [var]. 148

3.2 Pictorial illustration of the clauses [app], [jn] and [var]. 149
3.3 Preservation of analysis result. . . . . . . . . . . . . . 159
3.4 Initialisation of data structures for example program. . 179
3.5 Iteration steps of example program. . . . . . . . . . . 180
3.6 Control Flow and Data Flow Analysis for example program. . 185
4.1 Correctness relation R generated by representation function (3. 218

4.2 The complete lattice Interval= (Interval,[::;). 221
4.3 Fixed points of f. ............. 224
4.4 The widening operator V' applied to f. . 226
4.5 The narrowing operator ~ applied to f. 231
4.6 The Galois connection (L, a,"(, M) . ... 235
4.7 The complete lattice P(Sign) = (P(Sign), ~). 238
4.8 The Galois insertion (L, a,"(, M) . .. 243
4.9 The reduction operator~: M----+ M. 245
4.10 The complete lattice (Sign', [::;). . . 276
5.1 The memory model for the stack-based implementation of FuN.331

5.2 The pipeline produced by pipe [f 1 , f2J inp out. . . . . . 340
6.1 Example: LIFO iteration. . . . . . . . . . . . . . . . . . . . 374

6.2 (a) Graphical representation. (b) Depth-first spanning tree. 376
6.3 Example: Reverse postorder iteration. 377
6.4 Example: Round Robin iteration. . . . 379
6.5 (a) Strong components. (b) Reduced graph. 382
6.6 Example: Strong component iteration. 384
A.1 Two complete lattices. . . . 394

A.2 Two partially ordered sets. 400
A.3 Fixed points of f. . . . . . . 403
List of Figures XXI
C.l A fl.ow graph . . . . . . . . . . . . . . . 422

C.2 A DFSF for the graph in Figure C.l. . 423
C.3 An irreducible graph. . . . . . . . . . . 425
Chapter 1
Introduction
In this book we shall introduce four of the main approaches to program

analysis: Data Flow Analysis, Constraint Based Analysis, Abstract Interpre-
tation, and Type and Effect Systems. Each of Chapters 2 to 5 deals with one
of these approaches at some length and generally treats the more advanced
material in later sections. Throughout the book we aim at stressing the many
similarities between what may at a first glance appear to be very unrelated
approaches. To help to get this idea across, and to serve as a gentle intro-
duction, this chapter treats all of the approaches at the level of examples.
The technical details are worked out but it may be difficult to apply the
techniques to related examples until some of the material of later chapters
has been studied.
1.1 The Nature of Program Analysis

Program analysis offers static compile-time techniques for predicting safe
and computable approximations to the set of values or behaviours arising
dynamically at run-time when executing a program on a computer. A main
application is to allow compilers to generate code avoiding redundant com-
putations, e.g. by reusing available results or by moving loop invariant com-
putations out of loops, or avoiding superfluous computations, e.g. of results
known tobe not needed or of results known already at compile-time. Among
the more recent applications is the validation of software (possibly purchased
from sub-contractors) to reduce the likelihood of malicious or unintended be-
haviour. Common for these applications is the need to combine information
from different parts of the program.
A main aim of this book is to give an overview of a number of approaches to
program analysis, all of which have a quite extensive literature, and to show
2 1 Introduction
true answer
1
1
1
1
1
{d1, · · ·, dn, · · ·, dn+m}
safe answer
Figure 1.1: The nature of approximation: erring on the safe side.
that there is a large amount of commonality among the approaches. This

should help in cultivating the ability to choose the right approach for the
right task and in exploiting insights developed in one approach to enhance
the power of other approaches.
One common theme behind ali approaches to program analysis is that in
order to remain computable one can only provide approximate answers. As
an example consider a simple language of statements and the program
read(x); (if x>O then y:=l else (y:=2;S)); z:=y
where S is some statement that does not contain an assignment to y. Intu-

itively, the values of y that can reach z: =y will be 1 or 2.
Now suppose an analysis claims that the only value for y that can reach z: =y
is in fact 1. While this seems intuitively wrong, it is in fact correct in the
case where S is known never to terminate for x :::; O and y = 2. But since
it is undecidable whether or not S terminates, we normally do not expect
our analysis to attempt to detect this situation. So in general, we expect the
program analysis to produce a possibly larger set of possibilities than what
will ever happen during execution of the program. This means that we shall
also accept a program analysis claiming that the values of y reaching z : =y
are among 1, 2 or 27, although we will clearly prefer the analysis that gives
the more precise answer that the values are among 1 or 2. This notion of
safe approximation is illustrated in Figure 1.1. Clearly the challenge is not to
1.2 Setting the Scene 3
produce the safe "{ d1, · · · , dN }" too often as the analysis will then be utterly
useless. Note, that although the analysis does not give precise information it
may still give useful information: knowing that the value of y is one of 1, 2
and 27 just before the assignment z: =y still tells us that z will be positive,
and that z will fit within 1 byte of storage etc. To avoid confusion it may
help to be precise in the use of terminology: it is better to say "the values
of y possible at z : =y are among 1 and 2" than the slightly shorter and more
frequently used "the values of y possible at z: =y are 1 and 2".
Another common theme, to be stressed throughout this book, is that all
program analyses should be semantics based: this means that the information
obtained from the analysis can be proved to be safe (or correct) with respect
to a semantics of the programming language. It is a sad fact that new program
analyses often contain subtle bugs, and a formal justification of the program
analysis will help finding these bugs sooner rather than later. However, we
should stress that we do not suggest that program analyses be semantics
directed: this would mean that the structure of the program analysis should
reflect the structure of the semantics and this will be the case only for a few
approaches which are not covered in this book.
1.2 Setting the Scene

Syntax of the WHILE language. We shall consider a simple im-
perative language called WHILE. A program in WHILE is just a statement
which may be, and normally will be, a sequence of statements. In the interest
of simplicity, we will associate data fl.ow information with single assignment
statements, the tests that appear in conditionals and loops, and skip state-
ments. We will require a method to identify these. The most convenient
way of doing this is to work with a labelled program - as indicated in the
syntax below. We will often refer to the labelled items (assignments, tests
and ski p statements) as elementary blocks. In this chapter we will assume
that distinct elementary blocks are initially assigned distinct labels; we could
drop this requirement, in which case some of the examples would need to be
slightly reformulated and the resultant analyses would be less accurate.
We use the following syntactic categories:
a E AExp arithmetic expressions
b E BExp boolean expressions
S E Stmt statements
We assume some countable set of variables is given; numerals and labels will
not be further defined and neither will the operators:
x,y E Var variables
n E Num numerals
f E Lab labels
4 1 Introduction
f RDentry(f) RDexit(f)
1 (x, ?),(y, ?),(z, ?) (x,?),(y,l),(z,?)
2 (x, ?),(y,l),(z, ?) (x,?),(y,l),(z,2)
3 (x, ?),(y,l),(y,5),(z,2),(z,4) (x,?),(y,l),(y,5),(z,2),(z,4)
4 (x, ?),(y,l),(y,5),(z,2),(z,4) (x,?),(y,l),(y,5),(z,4)
5 (x, ?),(y,l),(y,5),(z,4) (x, ?),(y,5), (z,4)
6 (x, ?),(y,l),(y,5),(z,2), (z,4) (x, ?),(y,6), (z,2), (z,4)
Table 1.1: Reaching Definitions information for the factorial program.
opa E Opa arithmetic operators

opb E Opb boolean operators
opr E Opr relational operators
The syntax of the language is given by the following abstract syntax:
a x 1 n 1 a1 opa a2
b true 1 false 1 not b 1 b1 opb b2 1 a1 opr a2
8 .. - [x := a]i 1 [skip]i 1 81; 82 1
if [b]l then 81 else 82 1 while [b]l do 8
One way to think of the abstract syntax is as specifying the parse trees of
the language; it will then be the purpose of the concrete syntax to provide
sufficient information to enable unique parse trees to be constructed. In this
book we shall not be concerned with concrete syntax: whenever we talk about
some syntactic entity we will always be talking about the abstract syntax so
there will be no ambiguity with respect to the form of the entity. We shall
use a textual representation of the abstract syntax and to disambiguate it
we shall use parentheses. For statements one often writes begin · · · end or
{ · · ·} for this but we shall feei free to use ( · · ·). Similarly, we use brackets
( · · ·) to resolve ambiguities in other syntactic categories. To cut down on the
number of brackets needed we shall use the familiar relative precedences of
arithmetic, boolean and relational operators.
Example 1.1 An example of a program written in this language is the

following which computes the factorial of the number stored in x and leaves
the result in z:
Reaching Definitions Analysis. The use of distinct labels allows

us to identify the primitive constructs of a program without explicitly con-
structing a flow graph (or flow chart). It also allows us to introduce a program
analysis tobe used throughout the chapter: Reaching Definitions Analysis,
or as it should be called more properly, reaching assignments analysis:
1.3 Data Flow Analysis 5
An assignment (called a definition in the classical literature) of

the form [x := a]" may reach a certain program point (typically
the entry or exit of an elementary block) if there is an execution
of the program where x was last assigned a value at f when the
program point is reached.
Consider the factorial program of Example 1.1. Here [y:=x] 1 reaches the
entry to [z: =1]2; to allow a more succinct presentation we shall say that
(y,1) reaches the entry to 2. Also we shall say that (x,?) reaches the entry to
2; here "?" is a special labei not appearing in the program and it is used to
record the possibility of an uninitialised variable reaching a certain program
point.
Full information about reaching definitions for the factorial program is then
given by the pair RD = (RDentry, RDexit) of functions in Table 1.1. Careful
inspection of this table reveals that the entry and exit information agree for
elementary blocks of the form [b]" whereas for elementary blocks of the form
[x := a]" they may differ on pairs (x, f'). We shall come back to this when
formulating the analysis in subsequent sections.
Returning to the discussion of safe approximation note that if we modify
Table 1.1 to include the pair (z,2) in RDentry(5) and RDexit(5) we still have
safe information about reaching definitions but the information is more ap-
proximate. However, if we remove (z,2) from RDentry(6) and RDexit(6) then
the information will no longer be safe - there exists a run of the factorial pro-
gram where the set { (x,?),(y,6),(z,4)} does not correctly describe the reaching
definitions at the exit of labei 6.
1.3 Data Flow Analysis

In Data Flow Analysis it is customary to think of a program as a graph: the
nodes are the elementary blocks and the edges describe how control might
pass from one elementary block to another. Figure 1.2 shows the flow graph
for the factorial program of Example 1.1. We shall first illustrate the more
common equational approach to Data Flow Analysis and then a constraint
based approach that will serve as a stepping stone to Section 1.4.
1.3.1 The Equational Approach

The equation system. An analysis like Reaching Definitions can be
specified by extracting a number of equations from a program. There are two
classes of equations. One class of equations relate exit information of a node
to entry information for the same node. For the factorial program
[y:=x]\ [z:=1] 2 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6
6 1 Introduction
1 [y:=x]l 1
1
l[z:=1FI
1
1[y>1j3 1-=no"------1 [y:=OJ61
1yes 1
1[z: =z*y]41
1
1[y:=y-1]51
Figure 1.2: Flow graph for the factorial program.
we obtain the following six equations:
RDexit(l) (RDentry(l)\ {(y, f) 1 f E Lab}) U {(y, 1)}

RDexit(2) = (RDentry(2)\{(z,f) 1f E Lab}) U {(z,2)}
RDexit(3) RDentry(3)
RDexit(4) (RDentry(4)\{(z,f) 1 f E Lab}) U {(z,4)}
RDexit (5) (RDentry(5)\ { (y, f) 1f ELab}) U { (y, 5)}
RDexit(6) (RDentry(6)\{(y,f) 1 f E Lab}) U {(y,6)}
These are instances of the following schema: for an assignment [x := a]fl'

we exclude all pairs (x, f) from RDentry (f') and add (x, f') in order to obtain
RDexit(f') - this reflects that x is redefined at f. For all other elementary
·Jf'
blocks [· · we let RDexit(f') equal RDentry(f') - reflecting that no variables
are changed.
The other class of equations relate entry information of a node to exit in-
formation of nodes from which there is an edge to the node of interest; that
is, entry information is obtained from all the exit information where control
could have come from. For the example program we obtain the following
equations:
RDentry(2) RDexit(l)
RDentry(3) RDexit(2) U RDexit(5)

RDentry(4) RDexit (3)
RDentry(5) RDexit(4)
In general, we write RDentry(t') = RDexit(f!) U · · · U RDexit(t'n) if f1, · · · ,fn

are all the labels from which control might pass to f. We shall consider more
precise ways of explaining this in Chapter 2. Finally, let us consider the
equation
RDentry(l) = {(x, ?) 1 x is a variable in the program}
that makes it clear that the labei "?" is to be used for uninitialised variables;
so in our case
RDentry(l) = {(x, ?), (y, ?), (z, ?)}
The least solution. The above system of equations defines the twelve
sets
RDentry(l), · · ·, RDexit(6)
in terms of each other. Writing RO for this twelve-tuple of sets we can regard
the equation system as defining a function F and demanding that:
To be more specific we can write
F(RO) = (Fentry(l)(RO), Fexit(l)(RO), · · ·, Fentry(6)(RO), Fexit(6)(RO))
where e.g.:
Fentry(3)(· · ·, RDexit(2), · · ·, RDexit(5), · · ·) = RDexit(2) U RDexit(5)
It should be clear that F operates over twelve-tuples of sets of pairs of vari-

ables and labels; this can be written as
where it might be natural to take Var*= Var and Lab* = Lab. However,
it will simplify the presentation in this chapter to let Var* bea finite subset
of Var that contains the variables occurring in the program S* of interest
and similarly for Lab*. So for the example program we might have Var*=
{x, y, z} and Lab* = {1, · · ·, 6, ?}.
It is immediate that (P(Var* x Lab*)) 12 can be partially ordered by setting
RO ~ R0 1
iff Vi : RDi <:;; RD~
8 1 Introduction
where RO = (R01, · · ·, R012) and similarly R0 1 = (RO~,···, R0~ 2 ). This

turns (P(Var* x Lab*)) 12 into a complete lattice (see Appendix A) with
least element
0= (0, ... '0)
and binary least upper bounds given by:
~ ~1 1 1
KU U Ru = (R01 U R0 1, · · ·, R012 U ROd
It is easy to show that F is in fact a monotone function (see Appendix A)

meaning that:
RO!;;;; R0 1 implies F(RO)!;;;; F(R0 1)
This involves calculations like
imply
and the details are left to the reader.

Consider the sequence (Fn(0))n and note that 0!;;;; F(0). Since Fis mono-
tone, a straightforward mathematical induction (see Appendix B) gives that
pn(0) !;;;; pn+1(0) for all n. All the elements of the sequence will be in
(P(Var* x Lab*)) 12 and since this is a finite set it cannot be the case that
all elements of the sequence are distinct so there must be some n such that:
pn+l(0) = Fn(0)
But since pn+ 1 (0) = F(Fn(0)) this just says that Fn(0) is a fixed point of F
and hence that Fn(0) is a solution to the above equation system.
In fact we have obtained the least solution to the equation system. To see
this suppose that RO is some other solution, i.e. RD = F(RO). Then a
straightforward mathematical induction shows that Fn(0) !;;;; RO. Hence
the solution Fn(0) contains the fewest pairs of reaching definitions that is
consistent with the program, and intuitively, this is also the solution we want:
while we can add additional pairs of reaching definitions without making
the analysis semantically unsound, this will make the analysis less usable as
discussed in Section 1.1. In Exercise 1.7 we shall see that the least solution
is in fact the one displayed in Table 1.1.
1.3.2 The Constraint Based Approach

The constraint system. An alternative to the equational approach
above is to use a constmint based approach. The idea is here to extract a
number of inclusions (or inequations or constraints) out of a program. We
shall present the constraint system for Reaching Definitions in such a way
that the relationship to the equational approach becomes apparent; however,
it is not a general phenomenon that the constraints are naturally divided into
two classes as was the case for the equations.
For the factorial program
[y:=x]\ [z:=1] 2 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6
we obtain the following constraints for expressing the effect of elementary
blocks:
RDexit(l) ::J RDentry(l)\{(y,l) Il E Lab}
RDexit(l) ::J {(y, 1)}
RDexit(2) ::J RDentry(2)\{(z,l) Il E Lab}
RDexit(2) ::J {(z, 2)}
RDexit(3) ::J RDentry(3)
RDexit(4) ::J RDentry(4)\{(z,l) Il E Lab}
RDexit(4) ::J { (z, 4)}
RDexit(5) ::J RDentry(5)\{(y,l) Il E Lab}
RDexit(5) ::J {(y, 5)}
RDexit(6) ::J RDentry(6)\{(y,l) Il E Lab}
RDexit(6) ::J {(y, 6)}
By considering this system a certain methodology emerges: for an assignment

[x := ajl' we have one constraint that excludes all pairs (x, l) from RDentry{l')
in reaching RDexit (l') and we have one constraint for incorporating (x, l');
for all other elementary blocks [· · ·]R' we just have one constraint that allows
everything in RDentry(f') to reach RDexit(f').
Next consider the constraints for more directly expressing how control may
flow through the program. For the example program we obtain the con-
straints:
RDentry(2) ::J RDexit(l)
RDentry(3) ::J RDexit(2)
In general, we have a constraint RDentry(f) ;::2 RDexit(l') if it is possible for
control to pass from l' tol. Finally, the constraint
RDentry(l) ;::2 {(x, ?), (y, ?), (z, ?)}
records that we cannot be sure about the definition point of uninitialised
variables.
10 1 Introduction
The least solution revisited. It is not hard to see that a solution

to the equation system presented previously will also be a solution to the
above constraint system. To make this connection more transparent we can
rearrange the constraints by collecting all constraints with the same left hand
side. This means that for example
RDexit(1) ::) RDentry(1)\{(y,f) 1 f E Lab}

RDexit{1) ::) {(y, 1)}
will be replaced by
RDexit(1) 2 (RDentry(1)\{(y,f) 1 f E Lab}) U {(y, 1)}
and clearly this has no consequence for whether or not RO is a solution. In

other words we obtain a version of the previous equation system except that
all equalities have been replaced by inclusions. Formally, whereas the equa-
tional approach demands that RO= F(RO), the constraint based approach
demands that RO:;;;) F(RO) for the same function F. It is therefore immedi-
ate that a solution to the equation system is also a solution to the constraint
system whereas the converse is not necessarily the case.
Luckily we can show that both the equation system and the constraint system
have the same least solution. Recall that the least solution to RO= F(RO)
is constructed as Fn(0) for a value of n such that pn(0) = pn+ 1 (0). If RO
is a solution to the constraint system, that is RO :; ;) F(RO), then 0!;;; RO is
immediate and the monotonicity of F and mathematical induction then gives
Fn(0) !;;; RO. Since Fn(0) is a solution to the constraint system this shows
that it is also the least solution to the constraint system.
In summary, we have thus seen a very strong connection between the equa-
tional approach and the constraint based approach. This connection is not
always as apparent as it is here: one of the characteristics of the constraint
based approach is that often constraints with the same left hand side are gen-
erated at many different places in the program and therefore it may require
serious work to collect them.
1.4 Constraint Based Analysis

The purpose of Control Flow Analysis is to determine information about
what "elementary blocks" may lead to what other "elementary blocks" . This
information is immediately available for the WHILE language unlike what is
the case for more advanced imperative, functional and object-oriented lan-
guages. Often Control Flow Analysis is expressed as a Constraint Based
Analysis as will be illustrated in this section.
Consider the following functional program:
1.4 Constraint Based Analysis 11
let f = fn x => x 1;
g = fn y => y+2;
h = fn z => z+3
in (f g) + (f h)
It defines a higher-order function f with formal parameter x and body x 1;

then it defines two functions g and h that are given as actual parameters to
f in the body of the let-construct. Semantically, x will be bound to each
of these two functions in turn so both g and h will be applied to 1 and the
result of the computation will be the value 7.
An application of f will transfer control to the body of f, i.e. to x 1, and
this application of x will transfer control to the body of x. The problem is
that we cannot immediately point to the body of x: we need to know what
parameters f will be called with. This is exactly the information that the
Control Flow Analysis gives us:
For each function application, which functions may be applied.
As is typical of functional languages, the labelling scheme used would seem

to have a very different character than the one employed for imperative lan-
guages because the "elementary blocks" may be nested. We shall therefore
labei all subexpressions as in the following simple program that will be used
to illustrate the analysis.
ExaiDple 1.2 Consider the program:
It calls the identity function fn x => x on the argument fn y => y and

clearly evaluates to fn y => y itself (omitting all [· · ·]R). •
We shall now be interested in associating information with the labels them-

selves, rather than with the entries and exits of the labels- thereby we exploit
the fact that there are no side-effects in our simple functional language. The
Control Flow Analysis will be specified by a pair (C, ji) of functions where
C(.e) is supposed to contain the values that the subexpression (or "elemen-
tary block") labelled .e may evaluate to and p(x) contain the values that the
variable x can be bound to.
The constraint system. One way to specify the Control Flow Anal-
ysis then is by means of a collection of constraints and we shall illustrate this
for the program of Example 1.2. There are three classes of constraints. One
class of constraints relate the values of function abstractions to their labels:
{fn x => [xjl} ~ C(2)
{fn y => [yj3} ~ C(4)
12 1 Introduction
These constraints state that a function abstraction evaluates to a closure

containing the abstraction itself. So the general pattern is that an occurrence
of [fn x => e]f in the program gives rise to a constraint {fn x => e} ~ C(t').
The second class of constraints relate the values of variables to their labels:
p(x) ~ C(l)
;J(y) ~ C(3)
The constraints state that a variable always evaluates to its value. So for
each occurrence of [x]f in the program we will have a constraint P(x) ~ C(t').
The third class of constraints concerns function application: for each applica-
tion point [e 1 e2]R, and for each possible function [fn x => e]R' that could be
called at this point, we will have: (i) a constraint expressing that the formal
parameter of the function is bound to the actual parameter at the application
point, and (ii) a constraint expressing that the result obtained by evaluating
the body of the function is a possible result of the application.
Our example program has just one application [[· · ·F [· · ·] 4 ] 5 , but there are
two candidates for the function, i.e. C(2) is a subset of the set {fn x => [x] 1 ,
fn y => [yj3}. If the function fn x => [x] 1 is applied then the two con-
straints are C(4) ~ p(x) and C(l) ~ C(5). We express this as conditionat
constraints:
{fn x => [x]l} ~ C(2) => C(4) ~ p(x)
{fn x => [x] 1 } ~ C(2) => C(l) ~ C(5)
Alternatively, the function being applied could be fn y => [yp and the cor-
responding conditiona! constraints are:
{tn y => [yJ 3} ~ C(2) => C(4) ~ ;J(y)
{tn y => [yp} ~ C(2) => C(3) ~ c(s)
The least solution. As in Section 1.3 we shall be interested in the

least solution to this set of constraints: the smaller the sets of values given
by Cand p, the more precise the analysis is in predicting which functions are
applied. In Exercise 1.2 we show that the following choice of Cand p gives a
solution to the above constraints:
C(l) {fn y => [yj3}
C(2) = {fn x => [xjl}
C(3) = 0
C(4) {fn y => [yj3}
c(s) = {fn y => [yj3}
p(x) {fn y => [y]3}
p(y) 0
Among other things this tells us that the function abstraction fn y => y is
never applied (since p(y) = 0) and that the program may only evaluate to
the function abstraction fn y => y (since C(5) = {fn y => [yj3}).
Note the similarities between the constraint based approaches to Data Flow
Analysis and Constraint Based Analysis: in both cases the syntactic structure
of the program gives rise to a set of constraints whose least solution is desired.
The main difference is that the constraints for the Constraint Based Analysis
have a more complex structure than those for the Data Flow Analysis.
1.5 Abstract Interpretation

The theory of Abstract Interpretation is a general methodology for calculat-
ing analyses rather than just specifying them and then relying on a posteriori
validation. To some extent the application of Abstract Interpretation is in-
dependent of the specification style used for presenting the program analysis
and so applies not only to the Data Flow Analysis formulation to be used
here.
Collecting semantics. As a preliminary step we shall formulate a so-

called collecting semantics that records the set of traces tr that can reach a
given program point:
tr E Trace =(Var x Lab)*
Intuitively, a trace will record where the variables have obtained their values
in the course of the computation. So for the factorial program
we will for example have the trace
((x, ?),(y, ?), (z, ?),(y,l),(z,2),(z,4),(y,5),(z,4),(y,5),(y,6))
corresponding to a run of the program where the body of the while-loop is

executed twice.
The traces contain sufficient information that we can extract a set of seman-
tically reaching definitions:
SRD(tr)(x) = l iff the rightmost pair (x,l') intr has l = l'
We shall write DOM(tr) for the set ofvariables for which SRD(tr) is defined,
i.e. x E DOM(tr) iffsome pair (x,l) occurs intr.
In order for the Reaching Definitions Analysis to be correct (or safe) we shall
require that it captures the semantic reaching definitions, that is, if tr is a
14 1 Introduction
possible trace just before entering the elementary block labelled P then we
shall demand that
't/x E DOM(tr): (x, SRD(tr)(x)) E RDentry(P)
in order to trust the information in RDentry(P) about the set of definitions

that may reach the entry to P. In later chapters, we will conduct proofs of
results like this.
The collecting semantics will specify a superset of the possible traces at the
various program points. We shall specify the collecting semantics CS in the
style of the Reaching Definitions Analysis in Section 1.3; more precisely, we
shall specify a twelve-tuple of elements from (P(Trace)) 12 by means of a set
of equations. First we have
CSexit(l) {tr: (y, 1) 1 tr E CSentry(1)}

CSexit (2) { tr : (z, 2) 1 tr E CSentry (2)}
CSexit (3) CSentry (3)
CSexit (4) {tr: (z,4) 1 tr E CSentry(4)}
CSexit (5) {tr: (y,5) 1 tr E CSentry(5)}
CSexit(6) {tr: (y,6) 1 tr E CSentry(6)}
showing how the assignment statements give rise to extensions of the traces.
Here we write tr : (x, P) for appending an element (x, P) to a list tr, that
is ((xl,PI),···, (xn,Pn)): (x,P) equals ((xl,PI),···,(xn,Pn),(x,P)). Further-
more, we have
CSentry (2) CSexit(l)

CSentry (3) CSexit(2) U CSexit(5)
CSentry(4) CSexit(3)
CSentry(5) CSexit (4)
CSentry(6) CSexit(3)
corresponding to the flow of control in the program; more detailed infor-
mation about the values of the variables would allow us to define the sets
CSentry(4) and CSentry(6) more precisely but the above definitions are suffi-
cient for illustrating the approach. Finally, we take
CSentry(l) = {((x, ?), (y, ?), (z, ?))}

corresponding to the fact that all variables are uninitialised in the beginning.
In the manner of the previous sections we can rewrite the above system of
equations in the form
......
'Y(Y)
.•
y
Figure 1.3: The adjunction (a,')').
where CS is a twelve-tuple of elements from (P(Trace))l 2 and where G is a

monotone function of functionality:
G: (P(Trace)) 12 --+ (P(Trace))l 2
As is explained in Appendix A there is a body of general theory that ensures
that the equation system in fact has a least solution; we shall write it as
lfp(G). However, since (P(Trace)) 12 is not finite we cannot simply use the
methods of the previous sections in order to construct lip( G).
Galois connections. As we have seen the collecting semantics operates

on sets of traces whereas the Reaching Definitions Analysis operates on sets of
pairs of variables and labels. To relate these "worlds" we define an abstraction
function a and a concretisation function 1' as illustrated in:
P(Trace)
1'
-- Q
P(Var x Lab)
The idea is that the abstraction function a extracts the reachability informa-
tion present in a set of traces; it is natural to define
a(X) = {(x, SRD(tr)(x)) 1 x E DOM(tr) 1\ tr E X}
where we exploit the notion of semantically reaching definitions.
The concretisation function 1' then produces all traces tr that are consistent
with the given reachability information:
'Y(Y) = {tr 1 'Vx E DOM(tr): (x,SRD(tr)(x)) E Y}
Often it is demanded that a and 1' satisfy the condition

a(X) ~ Y {=} X ~ 'Y(Y)
16 1 Introduction
and we shall say that (a, "f) is an adjunction, or a Galois connection, whenever
this condition is satisfied; this is illustrated in Figure 1.3. We shall leave it
to the reader to verify that (a, 'Y) as defined above does in fact fulfil this
condition.
Induced analysis. We shall now show how the collecting semantics

can be used to calculate (as opposed to "guess") an analysis like the one in
Section 1.3; we shall say that the analysis is an induced analysis. For this we
define
a(X1, .. ·, X12) = (a(X1), .. ·, a(X12))
1(YI."',Yl2) = ('Y(Yl), .. ·,"f(Yl2))
where a and 'Y are as above and we consider the function a o G o 1 of func-
tionality:
(a o G o 1) : (P(Var x Lab)? 2 ---+ (P(Var x Lab)) 12
This function defines a Reaching Definitions analysis in an indirect way. Since
G is specified by a set of equations (over P(Trace)) we can use o G o 1 to a
calculate a new set of equations (over P(Var x Lab)). We shall illustrate
this for one of the equations:
CSexit(4) = {tr: (z,4) 1 tr E CSentry(4)}
The corresponding clause in the definition of G is:
Gexit(4)(- · ·, CSentry(4), · · ·) = {tr : (z, 4) 1 tr E CSentry(4)}
We can now calculate the corresponding clause in the definition of a o G o 1:
a(Gexit(4)(1(· · ·, RDentry(4), · · ·)))
= a({tr: (z,4) 1 tr E "f(RDentry(4))})
= {(x,SRD(tr: (z,4))(x))
1 x E DOM(tr: (z, 4)),
't:/y E DOM(tr): (y, SRD(tr)(y)) E RDentry(4)}

= {(x,SRD(tr: (z,4))(x))
1 x =1- z, x E DOM(tr: (z,4)),
't:/y E DOM(tr) : (y, SRD(tr)(y)) E RDentry(4)}

U{(x,SRD(tr: (z,4))(x))
1 x = z, x E DOM(tr: (z,4)),
't:/y E DOM(tr) : (y, SRD(tr)(y)) E RDentry(4)}

= {(x, SRD(tr)(x))
1 x =1- z, x E DOM(tr),
Vy E DOM(tr): (y, SRD(tr)(y)) E RDentry(4)}
U{(z, 4)
1 Vy E DOM(tr): (y, SRD(tr)(y)) E RDentry(4)}
= (RDentry(4) \ {(z,f) 1 f E Lab}) U {(z,4)}

1.6 Type and Effect Systems 17
The resulting equation
RDexit(4) = (RDentry(4) \ {(z,i) 1 i E Lab}) U {(z,4)}
is as in Section 1.3. Similar calculations can be performed for the other

equations.
The least solution. As explained in Appendix A the equation system
has a least solution; we shall write it as lfp(ii o G o 1). It is interesting to

note that if one replaces the infinite sets Var and Lab with finite sets Var*
and Lab* as before, then the least fixed point of ii o G o 1 can be obtained
as (ii o G o 1)n(0') just as was the case for F previously.
In Exercise 1.4 we shall show that ii o G o 1 ~ F and that ii(Gn(0)) C
(ii o G o 1)n(0) ~ Fn(0) holds for all n. In fact it will be the case that
ii(lfp(G)) ~ lfp(ii o G o 1) ~ lfp(F)
and this just says that the least solution to the equation system defined by
ii o G o 1 is correct with respect to the collecting semantics, and similarly that
the least solution to the equation system of Section 1.3 is also correct with
respect to the collecting semantics. Thus it follows that we will only need to
show that the collecting semantics is correct- the correctness of the induced
analysis will follow for free.
For some analyses one is able to prove the stronger result ii o G o 1 = F.
Then the analysis is optimal (given the choice of approximate properties it
operates on) and clearly lfp(ii o G o 1) = lfp(F). In Exercise 1.4 we shall
study whether or not this is the case here.
1.6 Type and Effect Systems

A simple type system. The ideal setting for explaining Type and
Effect Systems is to consider a typed functional or imperative language.
However, even our simple toy language can be considered to be typed: a
statement S maps a state to a state (in case it terminates) and may therefore
be considered to have type ~ -7 ~ where ~ denotes the type of states; we
write this as the judgement:
S:~-7~
One way to formalise this is by the following utterly trivial system of axioms
and inference rules:
18 1 Introduction
[x := a]R : E -+ E
[skip]e : E -+ E
SI : E -+ E s2 : E -+ E
SI; s2 : E-+ E
if [b]f then S1 else S2 : E-+ E
S:E-+E
while [b]f do S : E -+ E
Often a Type and Effect System can be viewed as the amalgamation of two
ingredients: an Effect System and an Annotated Type System. In an Effect
System we typically have judgements of the form S : E ~ E where the effect
<p tells something about what happens when S is executed: for example this
may be which errors might occur, which exceptions might be raised, or which
files might be modified. In an Annotated Type System we typically have
judgements of the form S : E1 -+ E2 where the Ei describe certain properties
of states: for example this may be that a variable is positive or that a certain
invariant is maintained. We shall first illustrate the latter approach for the
WHILE language and then illustrate the Effect Systems using the functional
language.
1.6.1 Annotated Type Systems
Annotated base types. To obtain our first specification of Reaching

Definitions we shall focus on a formulation where the base types are anno-
tated. Here we will have judgements of the form
where RD 1 , RD2 E P(Var x Lab) are sets of reaching definitions. Based

on the trivial axioms and rules displayed above we then obtain the more
interesting ones in Table 1.2.
To explain these rules let us first explain the meaning of S : RD 1 -+ RD 2 in
terms of the developments performed in Section 1.3. For this we first observe
that any statement S will have one elementary block at its entry, denoted
init(S), and one or more elementary blocks at its exit, denoted final(S); for a
statement like if [x<yjl then [x: =yj2 el se [y: =xj3 we thus get init(- · ·) = 1
and final(···) = {2, 3}.
Our first (and not quite successful) attempt at explaining the meaning of
[ass] [x := a]R': RO__, ((RO\{(x,J!) 1 J! E Lab}) U {(x,J!')})
[skip] [skip]R' : RO __, RO
S1 : R01 __, R02 S2 : R02 __, R03

[seq]
S1; S2: R01 __, R03
S1 : R01 __, R02 S2 : R01 __, R02

[i.l]
if [b]R then S1 else S2 : R01 __, R02
S: RO__, RO
[wh]
while [b]R do S : RO __, RO
S: R02 __, R03

[sub] if R01 ~ R02 and R03 ~ R04
S: R01 __, R04
Table 1.2: Reaching Definitions: annotated base types.
S : R0 1 __, R0 2 then is to say that:

R01 = ROentry(init(S))
U{ROexit(f!) 1 J! E final(S)} = R02
This suffices for explaining the axioms for assignment and ski p: here the
formulae after the arrows correspond exactly to the similar equations in the
equational formulation of the analysis in Section 1.3. Also the rule for se-
quencing now seems rather natural. However, the rule for conditiona! is more
dubious: considering the statement if [x<y] 1 then [x: =yj2 el se [y: =xj3 once
more, it seems impossible to achieve that the then-branch gives rise to the
same set of reaching definitions as the else-branch does.
Our second (and successful) attempt at explaining the intended meaning of
S : R0 1 __, R0 2 then is to say that:
R01 s;; ROentry(init(S))
W E final(S) : ROexit(R) ~ R02
This formulation is somewhat closer to the development in the constraint
based formulation of the analysis in Section 1.3 and it explains why the last
rule, called a subsumption rule, is unproblematic. Actually, the subsumption
rule will solve our problem with the conditiona! because even when the then-
branch gives a different set of reaching definitions than the else-branch we
can enlarge both results to a common set of reaching definitions. Finally,
consider the rule for the iterative construct. Here we simply express that RO
is a consistent guess concerning what may reach the entry and exits of S -
this expresses a fixed point property.
20 1 Introduction
Example 1.3 To analyse the factorial program

[y:=xjl; [z:=1] 2 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6
of Example 1.1 we will proceed as follows. We shall write RDf for the set
{(x, ?), (y, 1), (y, 5), (z, 2), (z, 4)} and consider the body of the while-loop.
The axiom [ass] gives
[z: =z*y] 4 : RDf ---t { (x, ?), (y, 1), (y, 5), (z, 4)}
[y: =y-1] 5 : {(x, ?), (y, 1), (y, 5), (z, 4)} ---t {(x, ?), (y, 5), (z, 4)}
so the rule [seq] gives:
([z: =z*y] 4 ; [y: =y-1] 5 ): RDf ---t {(x, ?), (y, 5), (z, 4)}
Now {(x, ?), (y, 5), (z, 4)} ~ RDf so the subsumption rule gives:
We can now apply the rule [wh] and get:
Using the axiom [ass] we get:
[y:=xjl: {(x, ?), (y, ?), (z, ?)} ---t {(x, ?), (y, 1), (z, ?)}
[z:=1f: {(x, ?), (y, 1), (z, ?)} ---t {(x, ?), (y, 1), (z, 2)}
[y: =0] 6 : RDf ---t { (x, ?), (y, 6), (z, 2), (z, 4)}
Since {(x, ?), (y, 1), (z, 2)} ~ RDf we can apply the rules [seq] and [sub] to get
([y:=xjl; [z:=1] 2 ; while [y>1j3 do ([z:=z*y] 4 ; [y:=y-1]5); [y:=0] 6 ):

{(x, ?),(y, ?),(z, ?)} ---t {(x, ?),(y,6),(z,2), (z,4)}
corresponding to the result in Table 1.1. •

The system in Table 1.2 suffices for manually analysing a given program. To
obtain an implementation it will be natural to extract a set of constraints
similar to those considered in Section 1.3, and then solve them in the same
way as before. This will be the idea behind the approach taken in Chapter 5.
Annotated type constructors. Another approach to Reaching Def-

initions has a little bit of the flavour of Effect Systems in that it is the type
constructors (arrow in our case) that are annotated. Here we will have judge-
ments of the form X
S:~--t~
RD
[ass] [X ·-
.-
a]i .• L...
~ {x} l ~
{(x,i)} L...
[skip] [skip]i : E f E
S1 : E ~ E S2 : E ~ E
[seq]
S 1; S 2 :
~
L...
X1UX2
(RD 1\X2)URD2
1 ~
L...
S1 : E {J 1 ~ E S2 : E ~2 ~ E
[i~
[wh]
while [b]i do S : E :o~ E
S:E~ E
[sub] X'
if X' <;; X and RD <;; RD'
S:E~ E
Table 1.3: Reaching Definitions: annotated type constructors.
where X denotes the set of variables that definitely will be assigned in S and
RD denotes the set of reaching definitions that S might produce. The axioms
and rules are shown in Table 1.3 and are explained below.
The axiom for assignment simply expresses that the variable x definitely will
be assigned and that the reaching definition (x, f) is produced. In the rule
for sequencing the notation RD \X means {(x,f) E RD 1 x ţf X}. The
rule expresses that we take the union of the reaching definitions after having
removed entries from S 1 that are definitely redefined in S2 . Also we take the
union of the two sets of assigned variables. In the rule for conditiona! we
take the union of information about reaching definitions whereas we take the
intersection (rather than the union) of the assigned variables because we are
not completely sure what path was taken through the conditiona!. A similar
comment holds for the rule for the while-loop; here we can think of 0 as the
intersection between 0 (when the body is not executed) and X.
We have included a subsumption rule because this is normally the case for
such systems as we shall see in Chapter 5. However, in the system above there
is little need for it, and if one excludes it then implementation becomes very
straightforward: simply perform a syntax directed traversa! of the program
where the sets X and RD are computed for each subprogram.
Example 1.4 Let us once again consider the analysis of the factorial pro-
gram
22 1 Introduction
For the body of the while-loop we get
[z:=z*y] 4 : E {z} 1
{(z,4)}
E
[y:=y-1] 5 : E -uWw E
so the rule [seq] gives:
([z:=z*y] 4 ; [y:=y-1] 5 ): E {y,z}

{(y,5),(z,4)}
1 E
We can now apply the rule [wh] and get:
while [y>1j3 do ([z:=z*y] 4 ; [y:=y-1] 5 ): E 0

{(y,5),(z,4)} 1 E
In a similar way we get

([y:=xjl; [z:=1] 2 ): E {y,z}
{(y,l),(z,2)}
1 E
[y :=0] 6 : E {y} 1
{(y,6)}
E
so using the rule [seq] we obtain
([y:=x]l; [z:=1] 2 ; while [y>1j3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6 ):

E {y,z} 1 E
{(y ,6), (z,2) ,(z,4)}
showing that the program definitely will assign to y and z and that the final
value of y will be assigned at 6 and the final value of z at 2 or 4. •
Compared with the previous specifications of Reaching Definitions analy-

sis the f:l.avour of Table 1.3 is rather different: the analysis of a statement
expresses how information present at the entry will be modified by the state-
ment - we may therefore view the specification as a higher-order formulation
of Reaching Definitions analysis.
1.6.2 Effect Systems

A simple type system. To give the f:l.avour of Effect Systems let
us once more turn to the functional language. As above, the idea is to
annotate a traditional type system with analysis information, so let us start
by presenting a simple type system for a language with variables x, function
abstraction fn7r x => e (where 1r is the name ofthe abstraction), and function
application e1 e2. The judgements have the form
rl-e:r
where r is a type environment that gives types to all free variables of e and
T is the type of e. For simplicity we shall assume that types are either base
types such as int and bool or they are function types written r 1 ----> r2. The
type system is given by the following axioms and rules:
r f-- X: Tx if r(x) = Tx
r[x f-t rx]l-- e : T

r f-- fn1r X => e : Tx ----> T
r f-- e1 : T2 ----> T, r f-- e2 : 72

r f-- e1 e2 : T
So the axiom for variables just expresses that the type of x is obtained from
the assumptions of the type environment. The rule for function abstrac-
tion requires that we "guess" a type Tx for the formal parameter x and we
determine the type of the body of the abstraction under that additional as-
sumption. The rule for function application requires that we determine the
type of the operator as well as the argument and it implicitly expresses that
the operator must have a function type by requiring the type of e 1 to have
the form r2 ----> r. Furthermore the two occurrences of r2 in the rule implicitly
express that the type of the actual parameter must equal the type expected
by the formal parameter of the function.
Example 1.5 Consider the following version of the program of Exam-

ple 1.2
(fnx x => x) (fny y => y)
where we now have given fn x => x the name X and fn y => y the name
Y. To see that this program has type int ----> int we first observe that
[y f-t int]l-- y: int so:
[ ]1-- fny y => y : int ----> int
Similarly, we have [x f-+ int ----> int]l-- x : int ----> int so:
[ ]1-- fnx x => x : ( int ----> int) ----> ( int ----> int)
The rule for application then gives:
[ ]1-- (fnx x => x) (fny y => y) : int----> int

•
Effects. The analysis we shall consider is a Call-Tracking Analysis:
For each subexpression, which function abstractions may be ap-

plied during its evaluation.
24 1 Introduction
[var]
[fn]
Î'f-fiL,rx=>e:7x cpU{1r}1 7&0
Table 1.4: Call-tracking Analysis: Effect System.
The set of function names constitutes the effect of the subexpression. To

determine this information we shall annotate the function types with their
latent effect so for example we shall write int ~ int for the type of a
function mapping integers to integers and with effect {X} meaning that when
executing the function it may apply the function named X. More generally,
the annotated types 7 will either be base types or they will have the form
where <p is the effect, i.e. the names of the function abstractions that we
might apply when applying a function of this type.
We specify the analysis using judgements of the form
Î'f-e:7&r.p
r
where is the type environment that now gives the annotated type of ali
free variables, 7 is the annotated type of e, and r.p is the effect of evaluating
e. The analysis is specified by the axioms and rules in Table 1.4 which will
be explained below.
In the axiom [var] for variables we produce an empty effect because we assume
that the parameter mechanism is call-by-value and therefore no evaluation
takes place when mentioning a variable. Similarly, in the rule [fn] for function
abstractions we produce an empty effect: no evaluation takes place because
we only construct a closure. The body of the abstraction is analysed in
order to determine its annotated type and effect. This information is needed
to annotate the function arrow: ali the names of functions in the effect of
the body and the name of the abstraction itself may be involved when this
particular abstraction is applied.
Next, consider the rule [app] for function application e 1 e2 . Here we obtain
annotated types and effects from the operator e1 as well as the operand e2.
The effect of the application will contain the effect <p1 of the operator (because
we have to evaluate it before the application can take place), the effect <p2 of
1. 7 Algorithms 25
the operand (because we employ a call-by-value semantics so this expression

has to be evaluated too) and finally we need the effect cp of the function being
applied. But this is exactly the information given by the annotation of the
arrow in the type 7'2 ~ 7' of the operand. Hence we produce the union of
these three sets as the overall effect of the application.
Example 1.6 Returning to the program of Example 1.5 we have:

. {Y}
[ ] f-- fny y => y : 1nt __, int & 0
[ l ,- fnx
L {Y}
x => x : ( int __, int ) __,
{X} (. {Y}
1nt __, .
1nt ) & rA
'Il
[] f-- (fnx x => x) (fny y => y): int ~ int & {X}
This shows that our example program may (in fact it will) apply the function
fn x => x but that it will not apply the function fn y => y. •
For a more general language we will also need to introduce some form of
subsumption rule in the manner of Tables 1.2 and 1.3; there are different
approaches to this and we shall return to this later. Effect Systems are
often implemented as extensions of type inference algorithms and, depending
on the form of the effects, it may be possible to calculate them on the fly;
alternatively, sets of constraints can be generated and solved subsequently.
We refer to Chapter 5 for more details.
1. 7 Algorithms
Let us now reconsider the problem of computing the least solution to the
program analysis problems considered in Data Flow Analysis and Constraint
Based Analysis.
Recall from Section 1.3 that we consider twelve-tuples RO E (P(Var* x
Lab*)) 12 of pairs of variables and labels where each label indicates an ele-
mentary block in which the corresponding variable was last assigned. The
equation or constraint system gives rise to demanding the least solution to an
equation RO= F(RO) or inclusion RO;;;) F(RO) where Fis a monotone func-
tion over (P(Var* x Lab*)) 12 . Due to the finiteness of (P(Var* x Lab*)) 12
the desired solution is in both cases obtainable as Fn(iJ) for any n such that
pn+ 1 (i$) = pn(iJ) and we know that such an n does in fact exist.
Chaotic lteration. Naively implementing the above procedure soon

turns out to require an overwhelming amount of work. In later chapters we
shall see much more efficient algorithms and in this section we shall illustrate
the principle of Chaotic Iteration that lies at the heart of many of them. For
26 1 Introduction
INPUT: Example equations for Reaching Definitions
OUTPUT: The least solution: RO= (RD 1, · · ·, RD 12 )
METHOD: Step 1: Initialisation

RD1:=0; · · ·; RD12:=0
Step 2: Iteration
RDj =1 Fj(RD1. · · ·, RD 12 ) for some j
while
do RDj:=Fj(RD1, · · ·, RD12)
Table 1.5: Chaotic Iteration for Reaching Definitions.
this let us write
(RD1. · · ·, RD12)
(Fl(RO), ... 'F12(RO))
and consider the non-deterministic algorithm in Table 1.5. It is immediate

that there exists j such that RDj =1 Fj(RD1. · · ·, RD12) if and only if RO =1
F(RO). Hence if the algorithm terminates it will produce a fixed point of F;
that is, a solution to the desired equations or constraints.
Properties of the algorithm. To further analyse the algorithm we

shall exploit that
holds at ali points in the algorithm (where n is determined by pn+ 1 (0) =

Fn(0)): it clearly holds initially and, as will be shown in Exercise 1.6, it is
maintained during iteration. This means that if the algorithm terminates we
will have obtained not only a fixed point of F but in fact the least fixed point
(i.e. Fn(0)).
To see that the algorithm terminates note that if j satisfies
then in fact RDj C Fj(RD1, · · ·, RD12) and hence the size of RO increases by
at least one as we perform each iteration. This ensures termination since we
assumed that (P(Var* x Lab*)) 12 is finite.
The above algorithm is suitable for manually solving data flow equations and
constraint systems. To obtain an algorithm that is suitable for implemen-
tation we need to give more details about the choice of j so as to avoid an
extensive search for the value; we shall return to this in Chapters 2 and 6.
1.8 Transformations 27
[ass1] RO f- [x := a]R l> [x := a[y ~----+ n]]"

if { y E FV(a) A (y, ?) ~ ROentry(l) A 1 1
V(z,l') E ROentry(l): (z = y =} [· · ·]R is [y := n]R)
[ass2] RO f- [x := a]R l> [x := n]R

if FV(a) = 0 A a~ Num A a evaluates ton
RO f- 81 l> 8~
RO f- 81; 82 l> 8~;82
RO f- 82 l> 8~
RO f- 81; 82 l> 81;8~
RO f- 81 l> 8~
[i/1]
RO f- i f [b]R then 81 else 82 l> i f [b]R then 8~ else 82
RO f- 82 l> 8~
[ih]
RO f- if [b]R then 81 else 82 l> if [b]R then 81 else 8~
RO f- 8 1> 8'
[wh]
RO f- while [b]R do 8l> while [b]R do 8'
Table 1.6: Constant Folding transformation.
1.8 Transformations
A major application of program analysis is to transform the program (at the

source level or at some intermediate level inside a compiler) so as to obtain
better performance. To illustrate the ideas we shall show how Reaching Defi-
nitions can be used to perform a transformation known as Constant Folding.
There are two ingredients in this. One is to replace the use of a variable in
some expression by a constant if it is known that the value of the variable will
always be that constant. The other is to simplify an expression by partially
evaluating it: subexpressions that contain no variables can be evaluated.
Source to source transformat ion. Consider a program 8* and let

RO be a solution (preferable the least) to the Reaching Definitions Analysis
for 8*. For a sub-statement 8 of 8* we shall now describe how to transform
it into a "better" statement 8'. We do so by means of judgements of the
form
RO f- 8 1> 8'
28 1 Introduction
expressing one step of the transformation process. We may define the trans-
formation using the axioms and rules in Table 1.6; they are explained below.
The first axiom [ass 1 ] expresses the first ingredient in Constant Folding as
explained above ~ the use of a variable can be replaced with a constant if it is
known that the variable always will be that constant; here we write a[y f--7 n]
for the expression that is as a except that all occurrences of y have been
replaced by n; also we write FV( a) for the set of variables occurring in a.
The second axiom [ass2 ] expresses the second ingredient of the transformation
~ expressions can be partially evaluated; it uses the fact that if an expression
contains no variables then it will always evaluate to the same value.
The last five rules in Table 1.6 simply say that if we can transform a sub-
statement then we can transform the statement itself. Note that the rules
(e.g. [seq1 ] and [seq2 ]) do not prescribe a specific transformation order and
hence many different transformation sequences may exist. Also note that the
relation RO f-- · [> · is neither reflexive nor transitive because there are no
rules that forces it to be so. Hence we shall often want to perform an entire
sequence of transformations.
Example 1. 7 To illustrate the use of the transformation consider the pro-

gram:
[x:=10F; [y:=x+10] 2 ; [z:=y+10P
The least solution to the Reaching Definitions Analysis for this program is:
ROentry(1) {(x, ?), (y, ?),(z, ?)}

ROexit(1) {(x, 1), (y, ?),(z, ?)}
ROentry(2) {(x, 1), (y, ?),(z, ?)}
ROexit(2) {(x, 1),(y,2), (z, ?)}
ROentry(3) {(x, 1),(y,2), (z, ?)}
ROexit(3) {(x,1), (y,2), (z,3)}
Let us now see how to transform the program. From the axiom [ass 1 ] we
have
RO f-- [y: =x+10] 2 [> [y: =10+10] 2
and therefore the rules for sequencing gives:
RO f-- [x: =10] \ [y: =x+10] 2 ; [z: =y+10] 3 [> [x: =10F; [y: =10+10] 2 ; [z: =y+10] 3
We can now continue and obtain the following transformation sequence:
RO f-- [x: =10F; [y: =x+10] 2 ; [z: =y+10] 3

[> [x: =10]\ [y: =10+10] 2 ; [z: =y+10] 3
[> [x:=10] 1 ; [y:=20] 2 ; [z:=y+1op
[> [x:=10] 1 ; [y:=20] 2 ; [z:=20+10] 3
[> [x:=10] 1 ; [y:=20] 2 ; [z:=30] 3
after which no more steps are possible. •

Successive transformations. The above example shows that we
shall want to perform many successive transformations:
This could be costly because once S 1 has been transformed into S2 we might
have to recompute Reaching Definitions Analysis for S2 before the trans-
formation can be used to transform it into s3 etc. It turns out that it is
sometimes possible to use the analysis for S 1 to obtain a reasonable analysis
for S 2 without performing the analysis from scratch. In the case of Reaching
Definitions and Constant Folding this is very easy: if RD is a solution to
Reaching Definitions for Si and RD f- Si [> Si+ 1 then RD is also a solution to
Reaching Definitions for Si+l - intuitively, the reason is that the transforma-
tion only changed things that were not observed by the Reaching Definitions
Analysis.
Concluding Remarks
In this chapter we have briefly illustrated a few approaches (but by no means
all) to program analysis. Clearly there are many differences between the four
approaches. However, the main aim of the chapter has been to suggest that
there are also more similarities than one would perhaps have expected at
first sight: in particular, the interplay between the use of equations versus
constraints. It is also interesting to note that some of the techniques touched
upon in this chapter have close connections to other approaches to reasoning
about programs; especially, some versions of Annotated Type Systems are
closely related to Hoare's logic for partial correctness assertions.
As mentioned earlier, the approaches to program analysis covered in this book
are semantics based rather than semantics directed. The semantics directed
approaches include the denotational based approaches [27, 86, 115, 117] and
logic based approaches [19, 20, 81, 82].
Mini Projects
Mini Project 1.1 Correctness of Reaching Definitions
In this mini project we shall increase our faith in the Type and Effect System
of Table 1.3 by proving that it is correct. This requires knowledge of regular
expressions and homomorphisms to the extent covered in Appendix C.
30 1 Introduction
First we shall show how to associate a regular expression with each state-
ment. We define a function S such that S(S) is a regular expression for each
statement S E Stmt. It is defined by structural induction (see Appendix B)
as follows:
S([x :=a]e)
S([skip]e) A
S(S1;S2) S(Sl) · S(S2)
S(if [b]e then S 1 else S2) S(Sl) + S(S2)
S(while b do S) (S(S) )*
The alphabet is {!; 1 x E Var*,C E Lab*} where Var* and Lab* are finite
and non-empty sets that contain all the variables and labels, respectively, of
the statement S* of interest. As an example, for S* being
if [x>OF then [x:=x+1] 2 else ([x:=x+2] 3 ; [x:=x+3] 4 )
we have S(S*) =!~ + (!~ · !~).
Correctness of X. To show the correctness of the X component in

S : I; :0) I; we shall for each y E Var* define a homomorphism
as follows:
h ('e) ={ ! if y = x
y ·x A if y =J X
As an example hx(S(S*)) = ! + (! · !) and hy(S(S*)) =A using that A· A= A

and A + A = A. Next we write
hy(S(S)) ~ ! · !*
to mean that the language .C[hy(S(S))] defined by the regular expression

hy(S(S)) is a subset of the language .C[! · !*] defined by! · !*; this is equivalent
to
-<:Jw E .C[hy(S(S))] : hy(w) =A
and intuitively says that y is always assigned in S. Prove that
if S: I; :0) I; and y E X then hy(S(S)) ~ ! · !*
by induction on the shape of the inference tree establishing S : I; :0 ) I;

(see Appendix B for an introduction to the proof principle).
Exercises 31
Correctness of RD. To show the correctness of the RD component

in S : E {o ) E we shall for each y E Var* and f' E Lab* define a
homomorphism
as follows:
' ify=x 1\ i=f'
ht (!;) = { ? if y = X 1\ i -# f'
A ify#x
As an example h~(S(S*)) =! + (? · ?) and h~(S(S*)) =A. Next
ht (S(S)) ~ ((!+?)* ·?)+A
is equivalent to
-.3w E C[S(S)] : ht (w) ends in!
and intuitively means than the last assignment to y could not have been
performed at the statement labelled R.'. Prove that
if S: E {o) E and (y, f') f/. RD then ht (S(S)) ~ ((!+ ?)* · ?) +A
by induction on the shape of the inference tree establishing S: E {o) E. •
Exercises
Exercise 1.1 A variant of Reaching Definitions replaces RD E P(Var x
Lab) by RL E P(Lab ); the idea is that given the program, a labei should
suffice for finding the variables that may be assigned in some elementary
block bearing that labei. Use this as the hasis for modifying the equation
system given in Section 1.3 for RD to an equation system for RL. (Hint:
It may be appropriate to think of RD = {(x1, ?), · · ·, (xn, ?)} as meaning
RD = {(x1, ?xJ, · · ·, (xn, ?xJ} and then use RL = {?xp' · ·, ?xn}.) •
Exercise 1.2 Show that the solution displayed for the Control Flow Anal-
ysis in Section 1.4 is a solution. Also show that it is in fact the least solution.
(Hint: Consider the demands on C(2), C(4), p(x), C(l) and C(5).) •
Exercise 1.3 Let (a,')') be an adjunction, ora Galois connection, as ex-

plained in Section 1.5; this just means that a(X) ~ Y {::} X ~ ')'(Y) holds
for all X and Y. Show that a uniquely determines ')' in the sense that ')' = ')' 1
whenever (a, ')' 1 ) is an adjunction. Also show that '/' uniquely determines a
for (a,')') being an adjunction. •
32 1 Introduction
Exercise 1.4 For F as in Section 1.3 and a, a, "f, 1 and G as in Section

1.5 show that a o G o 11;;:; F; this involves showing that
for all j and (R01, · · ·, R012). Determine whether or not F = aoGo1. Prove
by numerica! induction on n that (a o G o 1)n(0) !;;:; Fn(0). Also prove that
a(Gn(0))!;;:; (a o G o 1)n(0) using that a(0) = 0 and G!;;:; G o 1 o & •
Exercise 1.5 Consider the Annotated Type System for Reaching Defini-
tions defined in Table 1.2 in Section 1.6 and suppose that we want to stick
to the first (and unsuccessful) explanation of what S: R0 1 ----+ R0 2 means in
terms of Data Flow Analysis. Can you change Table 1.2 (by modifying or
removing axioms and rules) such that this becomes possible? •
Exercise 1.6 Consider the Chaotic Iteration algorithm of Section 1.7 and
suppose that
holds immediately before the assignment to ROj; show that is also holds
afterwards. (Hint: Write RO' for (R01, .. ·, Fj (RO), .. ·, R0 12) and use the
monotonicity of F and RO!;;:; F(RO) to establish that RO!;;:; R0 1 !;;:; F(RO) !;;:;
F(R0 1 ).) •
Exercise 1. 7 Use the Chaotic Iteration scheme of Section 1.7 to show
that the information displayed in Table 1.1 is in fact the least fixed point of
the function F defined in Section 1.3. •
Exercise 1.8 Consider the following program
computing the x-th power of the number stored in y. Formulate a system

of data flow equations in the manner of Section 1.3. Next use the Chaotic
Iteration strategy of Section 1. 7 to compute the least solution and present it
in a table (like Table 1.1). •
Exercise 1. 9 Perform Constant Folding upon the program

[x:=10]\ [y:=x+10] 2 ; [z:=y+x] 3
so as to obtain
[x:=10]\ [y:=20] 2 ; [z:=30] 3
How many ways of obtaining the result are there? •
Exercises 33
Exercise 1.10 The specification of Constant Folding in Section 1.8 only

considers arithmetic expressions. Extend it to deal also with boolean expres-
sions. Consider adding axioms like
RD f--- ([skip]c; S) [> S
RD f--- (if [true]c then S1 else S2) [> S1
and discuss what complications arise. •

Exercise 1.11 Consider adding the axiom
RD f--- [x := a]c [> [x := a[y f---+ a'W
if { y E F1V(a) 1\ (y, ?) ~ RD_:ntry(C) 1\ R' • ·- 1
R'
\f(z, C) E RDentry(C) . (y- Z::::} [· · ·] lS [y .-a] )
to the specification of Constant Folding given in Section 1.8 and discuss
whether or not this is a good idea. •
Chapter 2
Data Flow Analysis
In this chapter we introduce techniques for Data Flow Analysis. Data Flow
Analysis is the traditional form of program analysis which is described in
many textbooks on compiler writing. We will present analyses for the simple
imperative language WHILE that was introduced in Chapter 1. This includes
a number of classical Data Flow Analyses: Available Expressions, Reaching
Definitions, Very Busy Expressions and Live Variables. We introduce an
operational semantics for WHILE and demonstrate the correctness of the Live
Variables Analysis. We then present the notion of Monotone Frameworks
and show how the examples may be recast as such frameworks. We continue
by presenting a worklist algorithm for solving fl.ow equations and we study
its termination and correctness properties. The chapter concludes with a
presentation of some advanced topics, including Interprocedural Data Flow
Analysis and Shape Analysis.
Throughout the chapter we will clarify the distinctions between intraproce-
dural and interprocedural analyses, between forward and backward analyses,
between may and must analyses (or union and intersection analyses), between
flow sensitive and fl.ow insensitive analyses, and between context sensitive and
context insensitive analyses.
2.1 Intraproced ural Analysis

In this section we present a number of example Data Flow Analyses for
the WHILE language. The analyses are each defined by pairs of functions
that map labels to the appropriate sets; one function in each pair specifies
information that is true on entry to the block, the second specifies information
that is true at the exit.
36 2 Data Flow Analysis
Initial and final labels. When presenting examples of Data Flow

Analyses we will use a number of operations on programs and labels. The
first of these is
init : Stmt -+ Lab
which returns the initial label of a statement:
init([x := a]e) e
init([skip]e) e
init(S1; S2) init(SI)
init(if [W then 81 else S2) e
init(while [W do S) e
We will also need a function
final: Stmt -+ P(Lab)
which returns the set of final labels in a statement; whereas a sequence of

statements has a single entry, it may have multiple exits (as for example in
the conditiona!):
final([x := a]e) {e}

finai([skip]e) {C}
final(S1; S2) final(S2)
final(if [b]e then 81 else S2) final( SI) U final(S2)
finai(while [b]e do S) {e}
Note that the while-loop terminates immediately after the test has evaluated
to false.
Blocks. To access the statements or tests associated with a labei in a

program we use the function
blocks: Stmt-+ P(Blocks)
where Blocks is the set of statements, or elementary blocks, of the form

[x: =a]R or [skip]f as well as the set of tests of the form [W. It is defined as
follows:
blocks([x := a]e) {[x := a]e}

biocks([skip]e) {[skip]e}
blocks(S1; S2) blocks(SI) U blocks(S2)
blocks(if [b]e then 81 else S2) {[bn u blocks(S1) u blocks(S2)
blocks(while [b]e do S) {[bn u blocks(S)
2.1 Intraprocedural Analysis 37
Then the set of labels occurring in a program is given by
labels : Stmt --+ P(Lab)
where
labels(8) = {f 1 [B]t E blocks(8)}
Clearly init(8) E labels(8) and fina1(8) ~ labels(8).
Flows and reverse flows. We will need to operate on edges, or ftows,

between labels in a statement. We define a function
flow: Stmt--+ P(Lab x Lab)
which maps statements to sets of flows:
flow([x := a]l) 0
flow([skip]l) 0
f1ow(81; 82) flow(81) U f1ow(82)
U{(f,init(82)) 1 f E fina1(81)}
flow(if [b]l then 81 else 82) flow(81) U flow(82)
u{(f, init(81)), (f, init(82))}
flow(while [b]l do 8) flow(8) U {(f, init(8))}
U{ (e', f) 1 e' E fina1(8)}
Thus labels(8) and flow(8) will be a representation of the ftow graph of 8.
Example 2.1 Consider the following program, power, computing the x-th
power of the number stored in y:
[z:=1]\while [x>0] 2 do ([z:=z*y] 3 ; [x:=x-1] 4 )
We have init(power) = 1, finaJ(power) = {2} and Jabels(power) = {1, 2, 3, 4}.

The function flow produces the following set
{(1,2),(2,3),(3,4),(4,2)}
which corresponds to the flow graph in Figure 2.1. •

The function flow is used in the formulation of forward analyses. Clearly
init(8) is the (unique) entry node for the flow graph with nodes labels(8)
and edges flow( 8). Also
labels(8) = {init(8)} U {f 1 (f,e') E flow(8)} U {e' 1 (f,e') E flow(8)}
and for composite statements (meaning those not simply of the form [B]l)
the equation remains true when removing the {init(8)} component.
1 [z:=1jl 1
l
1 [x>O Fl--'n=o:..__--+
lyes
1 [z:=z*yp 1
Figure 2.1: Flow graph for the power program.
In order to formulate backward analyses we require a function that computes

reverse fiows:
flo~ : Stmt ---+ P(Lab x Lab)
It is defined by:
flo~(S) = {(P, i') 1 (i', P) E flow(S)}
Example 2.2 For the power program of Example 2.1, flo~ produces
{(2,1),(2,4), (3,2),(4,3)}
which corresponds to a modified version of the flow graph in Figure 2.1 where
the direction of the arcs has been reversed. •
In case final( S) contains just one element that will be the unique entry node
for the flow graph with nodes labels(S) and edges flo~(S). Also
labels(S) = final(S) U {i 1 (i,i') E flo~(S)} U {i' 1 (i,i') E flo~(S)}
and for composite statements the equation remains true when removing the
final(S) component.
The program of interest. We will use the notation S* to repre-

sent the program that we are analysing (the "top-level" statement), Lab* to
represent the labels (Jabels(S*)) appearing inS*, Var* to represent the vari-
ables (FV(S*)) appearing inS*, Blocks* to represent the elementary blocks
(blocks(S*)) occurring inS*, and AExp* to represent the set of non-trivial

arithmetic subexpressions in S*; an expression is trivial if it is a single vari-
able or constant. We will also write AExp(a) and AExp(b) to refer to the
set of non-trivial arithmetic subexpressions of a given arithmetic, respectively
boolean, expression.
To simplify the presentation of the analyses, and to follow the traditions of
the literature, we shall frequently assume that the program s* has isolated
entries; this means that:
This is the case whenever S* does not start with a while-loop. Similarly, we
shall frequently assume that the program s* has isolated exits; this means
that:
A statement, S, is label consistent if and only if:
[B1]l, [B2]l E blocks(S) implies B1 = B2

Clearly, if ali blocks inS are uniquely labelled (meaning that each labei occurs
only once), then S is labei consistent. When S is labei consistent the clause
"where [B]l E blocks(S)" is unambiguous in defining a partial function from
labels to elementary blocks; we shall then say that f labels the block B. We
shall exploit this when defining the example analyses below.
Example 2.3 The power program of Example 2.1 has isolated entries but
not isolated exits. It is clearly labei consistent as well as uniquely labelled. •
2.1.1 Available Expressions Analysis

The Available Expressions Analysis will determine:
For each program point, which expressions must have already

been computed, and not later modified, on ali paths to the pro-
gram point.
This information can be used to avoid the re-computation of an expression.

For clarity, we will concentrate on arithmetic expressions.
Example 2.4 Consider the following program:

[x:=a+b] 1 ; [y:=a*b] 2 ;while [y>a+b] 3 do ([a:=a+1] 4 ; [x:=a+b] 5 )
It should be clear that the expression a+b is available every time execution
reaches the test (labei 3) in the loop; as a consequence, the expression need
not be recomputed. •
kill and gen functions

killAE([x := a]l) {a' E AExp* 1 x E FV(a')}
kilJAE([skip]~) 0
killAE([W) 0
genAE([x := a]l) {a' E AExp(a) 1 x fj. FV(a')}
genAE([skipjl) 0
genAE([W) AExp(b)
data flow equations: AE=

if t' = init( s*)
{ ~{AEexit(t'') 1 (t'',t') E flow(S*)} otherwise
AEexit (t') (AEentry(t')\killAE(Bl)) U genAE(Bl)
where Bt E blocks(S*)
Table 2.1: Available Expressions Analysis.
The analysis is defined in Table 2.1 and explained below. An expression is

killed in a block if any of the variables used in the expression are modified in
the block; we use the function
killAE : Blocks* ----+ P(AExpJ
to produce the set of non-trivial expressions killed in the block. Test and
ski p blocks do not kill any expressions and assignments kill any expression
that uses the variable that appears in the left hand side of the assignment.
Note that in the clause for [x: =a]l we have used the notation a' E AExp*
to denote the fact that a' is a non-trivial arithmetic expression appearing in
the program.
A generated expression is an expression that is evaluated in the block and
where none of the variables used in the expression are later modified in the
block. The set of non-trivial generated expressions is produced by the func-
tion:
genAE : Blocks* ----+ P(AExp*)
The analysis itself is now defined by the functions AEentry and AEexit that
each map labels to sets of expressions:
For a label consistent program S* (with isolated entries) the functions can
be defined as in Table 2.1.
Figure 2.2: A schematic fl.ow graph.
The analysis is a forward analysis and, as we shall see, we are interested

in the largest sets satisfying the equation for AEentry - an expression will
be considered available if no path kills it. No expression is available at the
start of the program. Subsequently, the expressions that are available at the
entry to a block are any expressions that are available at all of the exits
from blocks that fl.ow to the block; if there are no such blocks the formula
evaluates to AExp*. Given a set of expressions that are available at the
entry, the expressions available at the exit of the block are computed by
removing killed expressions and adding any new expression generated by the
block.
To see why we require the largest solution, consider Figure 2.2 which shows
the fl.ow graph for a program in a schematic way. Such a flow graph might
correspond to the following program:
[z: =x+y]l; while [true]~" do [skip]l"
The set of expressions generated by the first assignment is {x+y}; the other
blocks do not generate expressions and no block kills any expressions. The
equations for AEentry and AEexit are as follows:
AEentry(l) = 0
AEentry(i') = AEexit(i) n AEexit (i")
AEentry(l") AEexit(i')
AEexit(i) AEentry(l) U {x+y}
AEexit(f') AEentry(i')
AEexit (f") AEentry(f")
After some simplification, we find that:
AEentry(f') = {x+y} n AEentry(C')
There are two solutions to this equation: {x+y} and 0o Consideration of

the example and the definition of available expressions shows that the most
informative solution is {x+y} - the expression is available every time we enter
C' o Thus we require the larg est solution to the equationso
Example 2.5 For the program

[x:=a+b]\ [y:=a*b] 2 ; while [y>a+b] 3 do ([a:=a+1] 4 ; [x:=a+b] 5 )
of Example 2.4, killAE and genAE are defined as follows:
c killAE(C) genAE(C)
1 0 {a+b}
2 0 {a*b}
3 0 {a+b}
4 {a+b, a*b, a+1} 0
5 0 {a+b}
We get the following equations:
AEentry(1) 0
AEentry(2) AEexit(1)
AEentry(3) AEexit (2) n AEexit (5)
AEentry(4) AEexit (3)
AEentry (5) AEexit(4)
AEexit (1) AEentry(1) U {a+b}
AEexit (2) AEentry (2) U { a*b}
AEexit (3) AEentry(3) U {a+b}
AEexit(4) AEentry(4)\ {a+b, a*b, a+1}
AEexit(5) AEentry (5) U { a+b}
Using an analogue of the Chaotic Iteration discussed in Chapter 1 (starting

with AExp* rather than 0) we can compute the following solution:
c AEentry(C) AEexit(C)
1 0 {a+b}
2 {a+b} {a+b, a*b}
3 {a+b} {a+b}
4 {a+b} 0
5 0 {a+b}
Note that, even though a is redefined in the loop, the expression a+b is re-
evaluated in the loop and so it is always available on entry to the loop. On
the other hand, a*b is available on the first entry to the loop but is killed
before the next iteration. •
2.1.2 Reaching Definitions Analysis

As mentioned in Chapter 1, the Reaching Definitions Analysis should more
properly be called reaching assignments but we will use the traditional name.
This analysis is analogous to the previous one except that we are interested
m:
For each program point, which assignments may have been made
and not overwritten, when program execution reaches this point
along some path.
A main application of Reaching Definitions Analysis is in the construction

of direct links between blocks that produce values and blocks that use them;
we shall return to this in Subsection 2.1.5.
Example 2.6 Consider the following program:

[x:=5] 1 ; [y:=1] 2 ;while [x>1] 3 do ([y:=x*y] 4 ; [x:=x-1] 5 )
All of the assignments reach the entry of 4 (the assignments labelled 1 and
2 reach there on the first iteration); only the assignments labelled 1, 4 and 5
reach the entry of 5. •
The analysis is specified in Table 2.2. The function
killRo : Blocks* ----. P(Var* x Lab:)
produces the set of pairs of variables and labels of assignments that are
destroyed by the block. An assignment is destroyed if the block assigns a
new value to the variable, i.e. the left hand side of the assignment. To deal
with uninitialised variables we shall, as in Chapter 1, use the special label
?
"?" and we set Lab~ = Lab* U {?}.
The function
genRo : Blocks* ----. P(Var* x Lab:)
produces the set of pairs of variables and labels of assignments generated by
the block; only assignments generate definitions.
The analysis itself is now defined by the pair of functions RDentry and RDexit
mapping labels to sets of pairs of variables and labels (of assignment blocks):
?
RDentry, RDexit: Lab* ____.. P(Var* X LabJ

killRo([x := a]l) {(x, ?)}
U{(x,.e') 1 Bl' is an assignment to x inS*}
killRo([skip]l) 0
killRo([W) = 0
genRo([x := ajl) {(x,f)}
genRo([skipjl) = 0
genRo([W) 0
data flow equations: RD=
{(x, ?) 1 x E FV(S*)} if f = init(S*)
RDentry(f) = { U{RDexit(.e') 1 (.e',f) E flow(S*)} otherwise
RDexit(f) = (RDentry(f)\killRo(Bl)) U genRo(Bl)
where Bl E blocks( S*)
Table 2.2: Reaching Definitions Analysis.
For a label consistent program S* (with isolated entries) the functions are
defined as in Table 2.2.
Similar to the previous example, this is a forward analysis but, as we shall
see, we are interested in the smallest sets satisfying the equation for RDentry·
An assignment reaches the entry of a block if it reaches the exit of any of
the blocks which precede it; if there are none the formula evaluates to 0.
The computation of the set of assignments reaching the exit of a block is
analogous to the Available Expressions Analysis.
We motivate the requirement for the smallest solution by consideration of
the program [z:=x+y]l;while [true]l' do [skip]l" corresponding to Figure
2.2 again. The equations for RDentry and RDexit are as follows:
RDentry(f) {(x, ?),(y, ?),(z, ?)}

RDentry (f') RDexit(i) URDexit(f")
RDentry(f") RDexit(f')
RDexit(f) (RDentry(f) \ {(z, ?)})U{(z,f)}
RDexit(f') RDentry(f')
RDexit (f") = RDentry (f")
Once again, we concentrate on the entry of the block labelled f', RDentry(l');
after some simplification we get
RDentry(f') = {(x, ?), (y, ?), (z,f)} U RDentry(f')
but this equation has many solutions: we can take RDentry(f') to be any
superset of {(x, ?), (y, ?), (z,f)}. However, since f' does not generate any new
definitions, the most precise solution is {(x, ?), (y, ?), (z, f)} - we require the
smallest solution to the equations.
Sometimes, when the Reaching Definitions Analysis is presented in the liter-
ature, one has RDentry(init(S*)) = 0 rather than RDentry(init(S*)) = {(x, ?) 1
x E FV(S*)}. This is correct only for programs that always assign variables
before their first use; incorrect optimisations may result if this is not the case.
The advantage of our formulation, as will emerge from Mini Project 2.2, is
that it is always semantically sound.
Example 2. 7 The following table summarises the assignments killed and

generated by each of the blocks in the program
of Example 2.6:
f killRo(f) genR 0 (f)

1 {(x, ?), (x,1),(x,5)} {(x,1)}
2 {(y, ?),(y,2),(y,4)} {(y, 2)}
3 0 0
4 {(y, ?), (y,2),(y,4)} {(y, 4)}
5 {(x, ?),(x,1), (x,5)} {(x, 5)}
The analysis gives rise to the following equations:
RDentry(1) = {(x, ?), (y, ?)}

RDentry(2) = RDexit(1)
RDentry(3) RDexit(2) U RDexit(5)
RDentry(4) = RDexit(3)
RDexit(1) (RDentry (1 )\ {(x, ?), (x, 1), (x, 5)}) U {(x, 1)}
RDexit (2) = (RDentry(2)\{(y, ?), (y, 2), (y,4)}) U {(y, 2)}
RDexit (3) RDentry(3)
RDexit(4) = (RDentry (4)\ { (y, ?), (y, 2), (y, 4)}) U {(y, 4)}
RDexit (5) (RDentry(5)\ { (x, ?), (x, 1), (x, 5)}) U { (x, 5)}
Using Chaotic Iteration we may compute the solution:
c RDentry(C) RDexit(C)
1 { (x, ?), (y, ?) } {(y, ?), (x, 1)}
2 {(y, ?), (x, 1)} {(x, 1), (y, 2)}
3 {(x,1),(y,2),(y,4),(x,5)} {(x, 1),(y,2), (y,4),(x,5)}
4 {(x,1),(y,2),(y,4),(x,5)} {(x,1),(y,4), (x,5)}
5 {(x,1),(y,4),(x,5)} {(y,4),(x,5)}
•
2.1.3 Very Busy Expressions Analysis
An expression is very busy at the exit from a label if, no matter what path
is taken from the label, the expression must always be used before any of the
variables occurring in it are redefined. The aim of the Very Busy Expressions
Analysis is to determine:
For each program point, which expressions must be very busy at

the exit from the point.
A possible optimisation based on this information is to evaluate the expres-

sion at the block and store its value for later use; this optimisation is some-
times called hoisting the expression.
Example 2.8 Consider the program:
The expressions a-b and b-a are both very busy at the start of the condi-
tiona!; they can be hoisted to the start of the conditiona} resulting in a space
saving in the size of the code generated for this program. •
The analysis is specified in Table 2.3. We have already defined the notion
of an expression being killed when we presented the Available Expressions
Analysis; we use an equivalent function here:
By analogy with the previous analyses, we also need to define how a block
generates additional very busy expressions. For this we use:
All of the expressions that appear in a block are very busy at the entry to
the block (unlike what was the case for Available Expressions).

killvs([x := a]i) = {a' E AExp* 1 x E FV(a')}
killvs([skip]i) 0
killvs([W) = 0
genv8 ([x := a]i) = AExp(a)
genv8 ([skip]i) = 0
genv 8 ([W) = AExp(b)
data flow equations: vs=

VBexit(f) { 0 if f E final(S*)
n{VBentry(f') 1 (f',f) E f:lo~(S*)} otherwise
(VBexit(f)\killvs(Bi)) U genv 8 (Bi)
where Bi E blocks(S*)
Table 2.3: Very Busy Expressions Analysis.
The analysis itself is defined by the pair of functions VBentry and VBexit
mapping labels to sets of expressions:
For a label consistent program S* ( with isolated exits) they are defined as in
Table 2.3.
The analysis is a backward analysis and, as we shall see, we are interested in
the largest sets satisfying the equation for VBexit· The functions propagate
information against the flow of the program: an expression is very busy at
the exit from a block if it is very busy at the entry to every block that follows;
if there are none the formula evaluates to AExp*. However, no expressions
are very busy at the exit from any final block.
To motivate the fact that we require the largest set, we consider the situation
where we have a flow graph as shown in Figure 2.3; this flow graph might
correspond to the program:
(while [x>l]i do [skip(); [x:=x+1(
The equations for this program are
VBentry(f) VBexit(f)
VBentry(f') VBexit(f')
VBentry(f") {x+1}
l
[8]-=no:..___[]j
fyes l
[]]
Figure 2.3: A schematic flow graph (in reverse).
VBexit (t') VBentry(t") n VBentry(t'")

VBexit(f') VBentry(t')
VBexit (t'") 0
and, for the exit conditions of t', we calculate:
VBexit(t') = VBexit(t') n {x+1}

Any subset of {x+1} is a solution but {x+1} is the most informative. Hence
we want the largest solution to the equations.
Example 2.9 To analyse the program
of Example 2.8, we calculate the following killed and generated sets:
t' killvs(t') genvs(t')

1 0 0
2 0 {b-a}
3 0 {a-b}
4 0 {b-a}
5 0 {a-b}
VBentry(l) VBexit(l)
VBentry(2) VBexit(2) U {b-a}
VBentry(3) = {a-b}
VBentry(4) VBexit(4) U {b-a}
VBentry(5) = {a-b}
VBexit(1) VBentry(2) n VBentry(4)

VBexit(2) VBentry(3)
VBexit(3) 0
VBexit(4) VBentry(5)
VBexit(5) 0
We can then use an analogue of Chaotic Iteration (starting with AExp*
rather than 0) to compute:
l VBentry(l) VBexit(f.)
1 {a-b, b-a} {a-b, b-a}
2 {a-b, b-a} {a-b}
3 {a-b} 0
4 {a-b, b-a} {a-b}
5 {a-b} 0
•
2.1.4 Live Variables Analysis
A variable is live at the exit from a labei if there exists a path from the
labei to a use of the variable that does not re-define the variable. The Live
Variables Analysis will determine:
For each program point, which variables may be live at the exit
from the point.
We shall take the view that no variables are live at the end of the program;
for some applications it might be better to assume that all variables are live
at the end of the program
Live Variables analysis may be used as the hasis for Dead Code Elimination.
If the variable is not live at the exit from a labei then, if the elementary block
is an assignment to the variable, the elementary block can be eliminated.
Example 2.10 Consider the following expression:
The variable x is not live at the exit from labei 1; the first assignment of the
program is redundant. Both x and y are live at the exit from labei 3. •
The analysis is defined in Table 2.4. The variable that appears on the left
hand side of an assignment is killed by the assignment; tests and skip state-
ments do not kill variables. This is expressed by the function:
killLv : Blocks* --t P(Var*)


killLv([x :=a]~') {x}
killLv([skip]~') 0
killLv([bjl') = 0
genLv([x := a]~') = FV(a)
genLv([skip]~') = 0
genLv([bjl') FV(b)
data fiow equations: Lv=
LVexit(t') { 0 if t' E final(S*)

U{LVentry(t") 1 (t",t') E f:lowR(S*)} otherwise
(LVexit(t')\killLv(B~')) U genLv(B~')
where B~' E blocks(S*)
Table 2.4: Live Variables Analysis.
The function
genLv: Blocks* ~ P(Var*)

produces the set of variables that appear in the block.
The analysis itself is defined by the pair of functions LV entry and LV exit map-
ping labels to sets of variables:
LVexit, LVentry: Lab* ~ P(Var*)

For a label consistent program S* (with isolated exits) they can be defined
as in Table 2.4. The equation for LV exit ( t') includes a variable in the set of
live variables (at the exit from t') if it is live at the entry to any of the blocks
that follow t'; if there are none then the formula evaluates to 0.
The analysis is a backward analysis and, as we shall see, we are interested in
the smallest sets satisfying the equation for LVexit· To see why we require
the smallest set, consider once again the program
(while [x>l]l' do [skip(); [x:=x+l('
corresponding to the fiow graph in Figure 2.3. The equations for the program
are:
LV entry ( t') LVexit(t') U {x}

LV entry ( t") LVexit(t")
LV entry(i") = {x}
LV exit(i) = LVentry(i') U LVentry(i")
LV exit (i') LVentry(i)
LV exit (i") 0
Suppose that we are interested in LVexit(i); after some calculation we get:
LV exit(i) = LV exit (i) U {X}
Any superset of {x} is a solution. Optimisations based on this analysis are

based on "dead" variables - the smaller the set of live variables, the more
optimisations are possible. Hence we shall be interested in the smallest solu-
tion {x} to the equations. Correctness of the analysis will be established in
Section 2.2.
Example 2.11 Returning to the program
[x:=2jl; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=zf
of Example 2.10, we can compute killLv and genLv as:
i killLv(i) genLv(i)
1 {x} 0
2 {y} 0
3 {x} 0
4 0 {x,y}
5 {z} {y}
6 {z} {y}
7 {x} {z}
LV entry (1) LVexit(1)\{x}

LVentry(2) LVexit(2)\{y}
LVentry(3) LVexit(3)\{x}
LVentry(4) LVexit(4) U {x,y}
LVentry(5) (LVexit(5)\{z}) U {y}
LVentry(6) (LVexit(6)\{z}) U {y}
LVentry(7) = {z}
LVexit(1) = LVentry(2)
LV exit( 4) LVentry(5) U LVentry(6)
LV exit(5) LV entry (7)

LVexit(6) LVentry(7)
LVexit(7) = 0
We can then use Chaotic Iteration to compute the solution:
f LVentry(f) LVexit(f)
1 0 0
2 0 {y}
3 {y} {x,y}
4 {x,y} {y}
5 {y} {z}
6 {y} {z}
7 {z} 0
Note that we have assumed that all variables are dead at the end of the
program. Some authors assume that the variables of interest are output at
the end of the program; in that case LV exit (7) should be {x, y, z} which means
that LVentry(7), LVexit(5) and LVexit(6) should all be {y,z}. •
2.1.5 Derived Data Flow Information

It is often convenient to directly link labels of statements that produce values
to the labels of statements that use them. Links that, for each use of a vari-
able, associate all assignments that reach that use are called Use-Dejinition
chains or ud-chains. Links that, for each assignment, associate all uses are
called Definition- Use chains or du-chains.
In order to make these definitions more precise, we will use the notion of a
definition clear path with respect to some variable. The idea is that f 1 , · · · , fn
is a definition clear path for x if none of the blocks labelled f 1, · · · , fn assigns
a value to x and if fn uses x. Formally, for a labei consistent program S* we
define the predicate clear:
clear(x,f,f') = :lf1,···,fn:
(fi = f) 1\ (fn = f') 1\ (n >O) 1\
(ViE {1, · · · ,n -1}: (fi,fi+I) E flow(S*)) 1\
(Vi E {1, .. ·, n- 1} : -,def(x, fi)) 1\ use(x, fn)
Here the predicate use checks whether the variable is used in a block
and the predicate def checks whether the variable is assigned in a block:
Armed with these definitions, we can define the functions
as follows:
ud(x, i') {i 1 def(x,i) 1\ :li": (i,i") E flow(S*) 1\ clear(x,i",l')}

U {? 1 clear(x,init(S*),i')}
{l' 1 def(x,l)
1\ 3l": (i,i") E flow(S*) 1\ clear(x,i",l')}
du(x, l) { iU :f: ?
{i' 1 clear(x,init(S*),l')}
iU=?
So ud(x, i') will return the labels where an occurrence of x at i' might have
obtained its value; this may be at a labei i in S* or x may be uninitialised as
indicated by the occurrence of "?". And du(x, i) will return the labels where
the value assigned to x at i might be used; again we distinguish between
the case where x gets its value within the program and the case where it is
uninitialised. It turns out that:
du(x,l) = {l' 1 i E ud(x,i')}
Before showing how ud- and du-chains can be used, we illustrate the functions
by a simple example.
Example 2.12 Consider the program:

[x:=O]\ [x:=3] 2 ; (if [z=x] 3 then [z:=0] 4 else [z:=x] 5 ); [y:=x] 6 ; [x:=y+zf
Then we get:
ud(x, i) X y z du(x, i) X y z
1 0 0 0 1 0 0 0
2 0 0 0 2 {3,5,6} 0 0
3 {2} 0 {?} 3 0 0 0
4 0 0 0 4 0 0 {7}
5 {2} 0 0 5 0 0 {7}
6 {2} 0 0 6 0 {7} 0
7 0 {6} {4,5} 7 0 0 0
? 0 0 {3}
The table for ud shows that the occurrence of x in block 3 will get its value
in block 2 and the table for du shows that the value assigned to x in block 2
may be used in block 3, 5 and 6. •
One application of ud- and du-chains is for Dead Code Elimination; for the
program of Example 2.12 we may remove the block labelled 1 for example
because there will be no use of the value assigned to x before it is reassigned

in the next block. Another application is in Code Motion; in the example
program the block labelled 6 can be moved to just in front of the conditiona!
because it only uses variables assigned in earlier blocks and the conditiona!
does not use the variable assigned in block 6.
The definitions of ud- and du-chains do not give any hints as to how to
compute the chains - the definitions are not constructive. It is possible to
give constructive definitions which re-use some of the functions that we have
defined in the earlier examples. In order to define ud-chains we can use
RD entry, which records the assignments reaching a block and define
by:
UD(x i) = { {i' 1 (x,l') E RDentry(l)} if x E ~enLv(Bl)
' 0 otherw1se
Similarly, we can define a function DU : Var* x Lab* ---+ P(Lab*) for du-
chains based on the functions we have seen previously. We shallleave this to
Mini Project 2.1 where we also consider the formal relationship between the
UD and DU functions and the functions ud and du.
2.2 Theoretical Properties

In this section we will show that the Live Variables Analysis of Subsection
2.1.4 is indeed correct; the correctness of the Reaching Definitions Analysis is
the topic of Mini Project 2.2. We shall begin by presenting a formal semantics
for WHILE.
The material of this section may be skimmed through on a first reading;
however, it is frequently when conducting the correctness proof that the final
and subtle errors in the analysis are found and corrected! In other words,
proving the semantic correctness of the analysis should not be considered a
dispensable development that is merely of interest for theoreticians.
2.2.1 Structural Operational Semantics

We choose to use a (so-called small step) Structural Operational Semantics
because it allows us to reason about intermediate stages in a program execu-
tion and it also allows us to deal with non-terminating programs.
Configurations and transitions. First define a state as a mapping
from variables to integers:
a E State Var---+ Z
2.2 Theoretical Properties 55
A : AExp - t (State - t Z)
A[x]a = a(x)
A[n]a N[n]
B : BExp - t (State - t T)
B[not b]a = -B[b]a
B[bt opb b2]a B[b1]a opb B[b2]a
B[a1 opr a2]a A[a1]a opr A[a2]a
Table 2.5: Semantics of expressions in WHILE.
A configuration of the semantics is either a pair consisting of a statement

and a state or it is a state; a terminal configuration is a configuration that
simply is a state. The transitions of the semantics are of the form
(S, a) -t a' and (S, a) -t (S', a')
and express how the configuration is changed by one step of computation.

So in the configuration (S, a) one of two things may happen:
• the execution terminates after one step and we record that by giving
the resulting state a', or
• the execution does not terminate after one step and we record that by
a new configuration (S', a') where S' is the rest of the program and a'
is the updated state.
To deal with arithmetic and boolean expressions we require the semantic

functions
A: AExp - t (State - t Z)
B: BExp - t (State - t T)
whose definition are given in Table 2.5. Here we assume that opa, opb and
opr are the semantic counterparts of the corresponding syntax. We have
also assumed the existence of N : N um - t Z which defines the semantics
of numerals. For simplicity we have assumed that no errors can occur; this
means that division by O will have to produce an integer for example. One
can modify the definition so as to allow errors but this will complicate the
correctness proof tobe performed below. Note that the value of an expression
is only affected by the variables appearing in it, that is:
if\ix E FV(a): a1(x) = a2(x) then A[a]a1 = A[a]a2
if\ix E FV(b): a1(x) = a2(x) then B[b]a1 = B[b]a2
[ass] ([x := a]i, a} --t a[x 1---t A[a]a]

[skip] ([skip]i, a} --t a
(81, a) --t (8~, a')

[seq1]
(81; 82, a) --t (8~; 82, a')
(8t. a) --t a'

[seq2]
(81; 82, a) --t (82, a')
[i/1] (if [bjl then 81 else 82,a) --t (81,a) if B[b]a = true
[i/2] (if rw then 81 else 82, a) --t (82, a} if B[b]a = false
[wh1] (while [bjl do 8, a) --t ((8; while [bjl do 8), a) if B[b]a = true
[w~] (while rw do 8, a} --ta if B[b]a = false
Table 2.6: The Structural Operational Semantics of WHILE.
These results can easily be proved by structural induction on expressions

(or by mathematical induction on their size); see Appendix B for a brief
introduction to these proof principles.
The detailed definition of the semantics of the statements may be found in
Table 2.6; it is explained below.
The clause [ass] specifies that the assignment x := a is executed in one step;
here we write a[x 1---t A[a]a] for the state that is as a except that x is mapped
to A[a]a, i.e. the value that a will evaluate to in the state a. Formally:
(ax
[ A[ ] ]) { A[a]a if x = y
1---t a a y = a(y) otherwise
The semantics of sequencing is given by the two rules [seq1] and [seq2 ] and
the idea is as follows. The first step of executing 8 1 ; 8 2 is the first step of
executing 8 1 . It may be that only one step is needed for 8 1 to terminate and
then the rule [seq2 ] applies and says that the new configuration is (82, a'}
refiecting that we are ready to start executing 82 in the next step. Alter-
natively, 8 1 may not terminate in just one step but gives rise to some other
configuration (8~, a'); then the rule [seq1 ] applies and it expresses that the
rest of 8 1 and all of 8 2 still have to be executed: the next configuration is
(8~;82,a').
The semantics of the conditiona! is given by the two axioms [ifd and [i/2 ] ex-
pressing that the first step of computation will select the appropriate branch
based on the current value of the boolean expression.

Finally, the semantics ofthe while-construct is given by the two axioms [wh1 ]
and [w~]; the first axiom expresses that if the boolean expressions evaluates
to true then the first step is to unroll the loop and the second axiom expresses
that the execution terminates if the boolean expression evaluates to false.
Derivation sequences. A derivation sequence for a statement S1 and

a state 0"1 can take one of two forms:
• It is a finite sequence of configurations (S1, 0"1), · · ·, (Sn, O"n), O"n+l sat-

isfying (Si,O"i)--+ (Si+1,0"i+1) for i = 1, · · · ,n-1 and (Sn,O"n)--+ O"n+1i
this corresponds to a terminating computation.
• It is an infinite sequence of configurations (S1, 0"1), ···,(Si, O"i), · · · satis-

fying (Si, O"i) --+ (Si+1, O"i+1) for all i ~ 1; this corresponds to a looping
computation.
Example 2.13 We illustrate the semantics by showing an execution of

the factorial program of Example 1.1. In the following we assume that the
state O"nxnynz maps x to nx, y to ny and z to nz. We then get the following
finite derivation sequence:
([y:=x]\ [z:=1f;while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6 ,0"3oo)
--+ ([z:=1] 2 ;while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6 ,0"33o)

--+ (while [y>1] 3 do ([z: =z*y] 4 ; [y: =y-1] 5 ); [y: =0] 6 , 0"331)
--+ ([z:=z*y] 4 ; [y:=y-1] 5 ;
while [y>1P do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6 ,0"331)
--+ ([y:=y-1] 5 ;while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6 ,0"333)
--+ (while [y>1] 3 do ([z: =z*y] 4 ; [y: =y-1] 5 ); [y: =0] 6 , 0"323)
--+ ([z:=z*y] 4 ; [y:=y-1] 5 ;
while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6 ,0"323 )
--+ ([y:=y-1] 5 ;while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6 ,0"326)
--+ (while [y>1] 3 do ([z: =z*y] 4 ; [y: =y-1] 5 ); [y: =0] 6 , 0"316)
--+ ([y: =0] 6 ' 0"316)

--+ 0"306
Note that labels have no impact on the semantics: they are merely carried
along and never inspected. •
Properties of the semantics. We shall first establish a number of

properties of the operations on programs and labels that we have used in
the formulation of the analyses. In the course of the computation the set of
flows, the set of finallabels and the set of elementary blocks of the statements
of the configurations will be modified; Lemma 2.14 shows that the sets will
decrease:
Lemma 2.14
(i) If (S, a) -+a' then final(S) = {init(S)}.
(ii) If (S, a)-+ (S', a') then final(S) ;:2 final(S').
(iii) If (S, a)-+ (S', a') then flow(S) ;:2 flow(S').
(iv) If (S,a)-+ (S',a') then blocks(S) ;:2 blocks(S') and if Sis labei con-
sistent then so is S'. •
Proof The proof of (i) is by induction on the shape of the inference tree used to
establish (8, a) -+ a'; we refer to Appendix B for a brief introduction to the proof
principle. Consulting Table 2.6 we see that there are three non-vacuous cases:
The case [ass]. Then ([x := a]e, a)-+ a[x f-> A[a]a] and we get:
iinal([x := a]e) = {f} = {init([x :=an}
The case [skip]. Then ([skip]e, a)-+ a and we get:
ilnal([skipn = {f} = {init([skipn}

The case [wh2]. Then (while [W do 8, a) -+a because B[b]a =false and we get:
ilnal(while [b]e do 8) = {l'} = {init(while [b]e do 8)}
This completes the proof of (i).
The proof of (ii) is by induction on the shape of the inference tree used to establish
(8, a) -+ (8', a'). There are fi ve non-vacuous cases:
The case [seq1]. Then (81;82,a)-+ (8~;82,a') because (81,a)-+ (8~,a') and we
get:
iinal(81; 82) = iinal(82) = iina1(8~; 82)
The case [seq2]. Then (81;82,a)-+ (82,a') because (81,a)-+ a' and we get:
iinal(S1; 82) = iinal(82)

The case (i/1]. Then (if [W then 81 else 82, a) -+ (81, a) because B[b]a = true
and we get:
The case [i/2 ] is similar to the previous case.

The case [wh1]. Then (while [W do S, u) --+ ((S; while [W do S), u) because B[b]u
= true and we get:
final(S; while [b]l do S) = final(while [b]t do S)
This completes the proof of (ii).

The proof of (iii) is by induction on the shape of the inference tree used to establish
(S, u) --+ (S', u'). There are fi ve non-vacuous cases:
The case [seq1]. Then (S1;S2,u)--+ (S~;S2,u') because (S1,u)--+ (S~,u') and we
get
fiow(S1;S2) fiow(S1) U fiow(S2) U {(f,init(S2)) 1 f E finaJ(S1)}

:J flow(SD U fiow(S2) U {(l, init(S2)) 1 f E finaJ(S1)}
:J flow(SD U fiow(S2) U {(l, init(S2)) 1 f E finaJ(S~)}
flow(S~; S2)
where we have used the induction hypothesis and (ii).

The case [seq2]. Then (S1;S2,u)--+ (S2,u') because (S1,CT)--+ u' and we get:
flow(Sl) U fiow(S2) U {(f, init(S2)) 1 f E final(S1)}

:J fiow(S2)
The case [i/1]. Then (if [W then S1 else S2, u) --+ (S~, u) because B[b]u = true
and we get:
fiow(S1) U fiow(S2)
U {(l, init(S1)), (f, init(S2))}
:J fiow(S1)
The case [i/2] is similar to the previous case.

The case [w~]. Then (while [W do S, u) --+ (S; while [b]t do S, u) because B[b]u
= true and we get:
flow(S; while [b]l do S) = flow(S) U fiow(while [b]f do S)

U { (l', f) Il' E final(S)}
flow(S) U fiow(S) U {(f, init(S))}
U {(l', f) Il' E finaJ(S)} U { (l', l) Il' E final(S)}
flow( S) U {(f, init( S))} U { (l', l) Il' E final( S)}
fiow(while [b]t do S)
This completes the proof of (iii).

The proof of (iv) is similar to that of (iii) and we omit the details. •
2.2.2 Correctness of Live Variables Analysis

Preservation of solutions. Subsection 2.1.4 shows how to define an
equation system for a label consistent program s* (with isolated exits); we will
refer to this system as LV=(s*). The construction of LV=(s*) can be modified
to give a constraint system LV~ (S*) of the form studied in Subsection 1.3.2:
LV exit ( f) ::J { 0 if .e E finaJ(S*)

U{LVentry(f') 1 (f',f) E Bo~(S*)} otherwise
(LV exit (f)\killLv(Bl)) U genLv(Bl)

where Bl E blocks(S*)
We make this definition because in the correctness proof we will want to use
the same solution for all statements derived from S*; this will be possible for
LV~(S*) but not for Lv=(s*).
Now consider a collection live of functions:
We say that live solves LV=(s), and write
if the functions satisfy the equations; similarly we write
live 1= LV~(S)
if li ve solves LV~ ( S*). The following result shows that any solution of the
equation system is also a solution of the constraint system and that the least
solutions of the two systems coincide.
Lemma 2.15 Consider a labei consistent program S*. If live 1= LV=(s*)

then live 1= LV~(S*). The least solution of LV=(s*) coincides with the least
solution of LV~(S*). •
Proof If live f= LV=(s*) then clearly live f= LV5:;(S*) because ":2" includes the
case of"=".
Next let us prove that LV5:;(S*) and LV=(s*) have the same least solution. We
gave a constructive proof of a related result in Chapter 1 (under some assumptions
about finiteness) so let us here give a more abstract proof using more advanced
fixed point theory (as covered in Appendix A). In the manner of Chapter 1 we
construct a function F(J. such that:
live f= LV5:; (S) iff li ve;::;) FLt(Jive)
live f= LV=(s) iff Jive = FLţ(Jive)

(S, a1) --+ (S',ai) --+ ... --+ (S",an --+ am

1
[ F LV' [ FLV' [ FLV'
li ve li ve li ve
Figure 2.4: Preservation of analysis result.
Using Tarski's Fixed Point Theorem (Proposition A.10) we now have that FL~ has
a least fixed point lip( FL~) such that
lip( F~) = n{li ve llive ;:::) FL~ (li ve)} = n{li ve llive = FL~ (li ve)}
and since lip( FL~) = FL~ (Jfp( FL~)) as well as lfp( F~) ;:::) FL~ (Jfp( F~)) this proves
the result. •
The next result shows that if we have a solution to the constraint system
corresponding to some statement sl then it will also be a solution to the
constraint system obtained from a sub-statement S 2; this result will be es-
sential in the proof of the correctness result.
Lemma 2.16 If live f= LV<;;;(S1) (with S1 being labei consistent) and

flow(SI) 2 flow(S2) and blocks(S1) 2 blocks(S2) then live f= LV<;;;(S2) (with
82 being labei consistent). •
Proof If 81 is label consistent and blocks(81) :2 blocks(82) then also 8 2 is label
consistent. If live f= LV<;; (81) then li ve also satisfies each constraint in LV<;; (82) and
hence live f= LV<;; (82). •
We now have the following corollary expressing that the solution to the con-
straints of LV<;;; is preserved during computation; this is illustrated in Figure
2.4 for finite computations.
Corollary 2.17 If live f= LV<;;;({) (for S being labei consistent) and if

(S,a)--+ (S',a') then also live f= LV-(S'). •
Proof Follows from Lemma 2.14 and 2.16. •
We also have an easy result relating entry and exit components of a solution.
Lemma 2.18 If live f= LV<;;;(S) (with S being labei consistent) then for
all (i,i') E flow(S) we have liveexit(i) 2 liveentry(i'). •
Proof The result follows immediately from the construction of LV<;;(8). •
(S, a1) ---+ (S',aD ---+ ... ---+ (S", an ---+ a~'
l-v ]-v· l-v" ]-x(t)

(S, a2) ---+ (S',a~) ---+ ... ---+ (S", a~) ---+ a~'
V= N(init(S)) V' = N(init(S')) V" = N(init(S")) lE final(S)
Figure 2.5: The correctness result for live.
Correctness relation. Intuitively, the correctness result for the Live

Variables Analysis should express that the sets of live variables computed by
the analysis are correct throughout the computation. Only the values of the
li ve variables are of interest for the computation: if a variable is not live then
its value in the state is irrelevant - its value cannot affect the interesting
parts of the result of the computation. Assume now that V is a set of live
variables and define the correctness relation:
a1 "'V a2 iff Vx E V: a1(x) = a2(x)
The relation expresses that for all practica! purposes the two states a 1 and
a2 are equal: only the values of the live variables matters and here the two
states are equal.
Example 2.19 Consider the statement [x:=y+z]R and let Vi= {y, z} and
V2 = {x}. Then a1 "'V1 a2 means a1(y) = a2(y) A a1(z) = a2(z) and
a1 "'V2 a2 means a1(x) = a2(x).
Next suppose that ([x:=y+z]R,a1)---+ a~ and ([x:=y+z]~',a2 )---+ a~. Clearly
a1 "'V1 a2 ensures that a~ "'v2 a~. So if V2 is the set of variables live after
[x: =y+z]l then vl is the set of variables live before [x: =y+z]l. •
The correctness result will express that the relation "rv" is an invariant under
the computation. This is illustrated in Figure 2.5 for finite computations and
it is formally expressed by Corollary 2.22 below; to improve the legibility of
formulae we write:
N (i) liveentry (i)
X (i) liveexit (i)

Since the live variables at the exit from a label are defined to be (a superset
of) the union of the live variables at the entries of all of it successor labels,
we have the following result. ·
Lemma 2.20 Assume live f= LV<;;: (S) with S being labei consistent. Then
o-1 "'X(€) o-2 implies o-1 "'N(l') o-2 for all (C,C') E flow(S). •
Proof Follows directly from Lemma 2.18 and the definition of "'V. •
Correctness result. We are now ready for the main result. It states
how semantically correct liveness information is preserved under each step of
the execution: (i) in the case where we do not immediately terminate and
(ii) in the case where we do immediately terminate.
Theorem 2.21
If live f= LV<;;:(S) (with S being labei consistent) then:
(i) if (S, o-1) ---. (S', a-~) and o-1 "'N(init(S)) o-2 then there exists
o-~ such that (S,a-2)---. (S',o-~) and o-~ rvN(init(S')) o-~, and
(ii) if (S, a-1) ___. o-~ and o-1 rvN(init(S)) o-2 then there exists o-~
such that (S,o-2)---. o-~ and o-~ rvx(init(S)) o-~
Proof The proof is by induction on the shape of the inference tree used to establish
(8,o-1)--+ (8',a~) and (8,a1)--+ a~, respectively.
The case [ass]. Then ([x := a]f,a1)--+ a![x f-+ A[a]a1] and from the specification
of the constraint system we have
N(P) = liveentry(P) ;;;> (liveexit(P)\{x}) U FV(a) = (X(P)\{x}) U FV(a)
and thus
a1 "'N(l) a2 implies A[a]a1 = A[a]a2
because the value of a is only affected by the variables occurring in it. Therefore,
taking
a;= a2[x f-+ A[a]a2]
we have that a~(x) = a~(x) and thus a~ "'X(i) a~ as required.
The case [skip]. Then ([skip]f, a1) --+ a1 and from the specification of the constraint
system
N(P) = liveentry(P) ;;;> (liveexit(f)\0) U 0 = liveexit(P) = X(P)
and we take a; to be a2.

The case [seq 1]. Then (81;82,a1)--+ (8~;82,aD because (81,a1)--+ (8~,aD. By
construction we have flow(81; 82) ;;;> flow(81) and also blocks(81; 82) ;;;> blocks(81).
Thus by Lemma 2.16, live is a solution to LV<;;(8 1 ) and thus by the induction
hypothesis there exists a;
such that
and the result follows.

The case [seq2]. Then (S1;S2,cr1)-+ (S2,crD because (S1,cr1)-+ cr~. Once again
by Lemma 2.16, live is a solution to LV<;;;(S!) and thus by the induction hypothesis
there exists cr; such that:
Now
{(i', init(S2)) PE final(S1)} <;;; flow(S1; S2)
1
and by Lemma 2.14, final(S1) = {init(Sl)}. Thus by Lemma 2.20
and the result follows.

The case [i/1]. Then (if [W then S1 else S2,cr1) -+ (S1,cr1) because B[b]cr1 =
true. Since cr1 rvN(€) cr2 and N(P) = liveentry(P) ::2 FV(b), we also have that
B[b]cr2 = true (the value of b is only affected by the variables occurring in it) and
thus:
(if [b]c then sl else s2, CT2) -+ (Sl, cr2)
From the specification of the constraint system, N (P) = liveentry (P) ::2 liveexit (P) =
X(P) and hence CTl rvx(C) CT2. Since (P,init(Sl)) E flow(S), Lemma 2.20 gives
CT1 rv N(init(Sl)) CT2 as required.
The case [i/2] is similar to the previous case.
Thecase [wh1]. Then(while [W do S,cr1)-+(S;while [W do S,cr1)becauseB[b]cr1
= true. Since cr1 rvN(C) cr2 and N(P) ::2 FV(b), we also have that B[b]cr2 = true and
thus
(while [b]c do S, cr2) -+ (S; while [b]c do S, cr2)
and again, since N(P) = liveentry(P) ::2 liveexit(P) = X(P) we have cr1 rvx(C) cr2 and
then
CTl rv N (init( S)) CT2
follows from Lemma 2.20 because (P,init(S)) E flow(while [W doS).
The case [wh2]. Then (while [W do S, cr1) -+ cr1 because B[b]cr1 = false. Since
cr1 rvN(€) cr2 and N(P) ::2 FV(b), we also have that B[b]cr2 =false and thus:
(while [b]c do S, cr2) -+ cr2
From the specification of LV<;;;(S), we have N(P) = liveentry(P) ::2 liveexit(P) = X(P)
and thus CT1 rv X (C) CT2.
This completes the proof. •
Finally, we have an important corollary which lifts the previous result to
program executions: (i) in the case where the derivation sequence has not
yet terminated and (ii) in the case it has terminated:
Corollary 2.22 If live p LV<==(S) (with S being labei consistent) then:
(i) if (S,cr1) -+* (S',crD and cr1 "'N(init(S)) cr2 then there exists cr2 such
that (S,cr2) -+* (S',crD and cr~ "'N(init(S')) cr2, and
2.3 Monotone Frameworks 65
(ii) if (S,a1) --+*a~ and a1 "'N(init(S)) a2 then there exists a~ such that
(S, a2) --+* a~ and a~ "'X(f) a~ for some f E final(S). •
Proof The proof is by induction on the length of the derivation sequence and uses
Theorem 2.21. •
Remark. We have now proved the correctness of Live Variables Analysis

with respect to a small step operational semantics. Obviously, the correctness
of the analysis can also be proved with respect to other kinds of semantics.
However, note that if one relies on, say, a big step (or natural) semantics then
it is not so obvious how to express (and prove) the correctness of looping
computations: in a big step semantics a looping computation is modelled by
the absence of an inference tree - in contrast to the small step semantics
where it is modelled by an infinite derivation sequence. •
2.3 Monotone Frameworks

Despite the differences between the analyses presented in Section 2.1, there
are sufficient similarities to make it plausible that there might be an un-
derlying framework. The advantages that accrue from identifying such a
framework include the possibility of designing generic algorithms for solving
the data flow equations, as we will see in Section 2.4.
The overall pattern. Each of the four classical analyses (presented in

Subsection 2.1.1 to 2.1.4) considers equations for a labei consistent program
s* and they take the form
iUE E
Analysis0 ( f)
{ U{Analysis.(f') 1 (f',f) E F} otherwise
Analysis. (f) h (Analysis 0 ( f))
where
• uis n or u (and u is u or n)'

• Fis either flow(S*) or flo~(S*),
• t specifies the initial or final analysis information, and
• fi is the transfer function associated with Bi E blocks( S*).
We now have the following characterisation:

• The forward analyses have F to be flow( S*) and then Analysis0 con-
cerns entry conditions and Analysis. concerns exit conditions; also the
equation system presupposes that s* has isolated entries.
• The backward analyses have F to be flo~(S*) and then Analysis0

concerns exit conditions and Analysis. concerns entry conditions; also
the equation system presupposes that s* has isolated exits.
The principle we have seen emerging in Section 2.1 is that:
• When U is n
we require the greatest sets that solve the equations
and we are able to detect properties satisfied by all paths of execution
reaching (or leaving) the entry (or exit) of a label; these analyses are
often called must analyses.
• When U is U we require the least sets that solve the equations and we
are able to detect properties satisfied by at least one execution path to
(or from) the entry (or exit) of a labei; these analyses are often called
may analyses.
Remark. Some authors propose a typology for Data Flow Analysis, char-
acterising each analysis by a triple from
where--+ means forwards, +-- means backwards, 1 means smallest and l means
largest. This leads to eight possible types of analysis- a cube. In fact, given
our association of n
with l and U with L the cube collapses to a square.
We have presented analyses of the following four types: (n, --+, l), (U, --+, 1),
(n, ,_, n and (U, ,_, 1). •
It is occasionally awkward to have to assume that forward analyses have iso-
lated entries and that backward analyses have isolated exits. This motivates
reformulating the above equations to be of the form
Analysis0 ( C) U{Analysis.(C') 1 (C',C) E F} U t~

iUE E
where R
tE = { t_l
iU~ E
Analysis. (C) fe (Analysis0 ( C))
where _l satisfies l U _i = l (hence _l is not really there). This formulation

makes sense also for analyses that do not have isolated entries and exits.
In this section, we present a more formal approach to defining data flow
frameworks that exploits the similarities that we have identified above. Noth-
ing that we present in this section is dependent on the definition of elementary
blocks, or the programming language constructs; however, the techniques do

not directly apply to languages with procedures (which will be addressed in
Section 2.5). The view that we take here is that a program is a transition
system; the nodes represent blocks and each block has a transfer function as-
sociated with it that specifies how the block acts on the "input" state. (Note
that for forward analyses, the input state is the entry state, and for backward
analyses, it is the exit state.)
2.3.1 Basic Definitions

Property spaces. One important ingredient in the framework is the
property space, L, used to represent the data flow information as well as
the combination operator, U : P (L) ---+ L, that combines information from
different paths; as usual U : L x L ---+ L is defined by h U h = U{l1, l 2 }
and we write l_ for U0. It is customary to demand that this property space
is in fact a complete lattice; as discussed in Appendix A this just means
that it is a partially ordered set, (L, ~), such that each subset, Y, has a
least upper bound, UY. Looking ahead to the task of implementing the
analysis one often requires that L satisfies the Ascending Chain Condition;
as discussed in Appendix A this means that each ascending chain, (ln)n,
i.e. h ~ l 2 ~ l3 ~ · · ·, eventually stabilises, i.e. ::In : ln = ln+l = · · ·.
Example 2.23 For Reaching Definitions we haveL= P(Var* x Lab:)

and it is partially ordered by subset inclusion, i.e. "~" is "<:;;;". Similarly, U Y
is U Y, h U h is h U l2, and l_ is 0. That L satisfies the Ascending Chain
Condition, i.e. that h <:;;; l2 <:;;; · · · implies ::In : ln = ln+l = · · ·, follows because
Var* x Lab: is finite (unlike Var x Lab). •
Example 2.24 For Available Expressions we haveL= P(AExpJ and

it is partially ordered by superset inclusion, i.e. "~" is ";;:?". Similarly, UY
n
is Y, h U l2 is h n l2, and l_ is AExp*. That L satisfies the Ascending
Chain Condition, i.e. that h ;;:? l2 ;;:? · · · implies ::In : ln = ln+l = · · ·, follows
because AExp* is finite (unlike AExp). •
Remark. Historically, the demands on the property space, L, have often

been expressed in a different way. A join semi-lattice is a non-empty set,
L, with a binary join operation, U, which is idempotent, commutative and
associative, i.e. l U l = l, h U h = l2 U h and (h U l2) U h = h U (l2 U l3 ).
The commutativity and associativity of the operation mean that it does not
matter in which order we combine information from different paths. The join
operation induces a partial ordering, ~' on the elements by taking h ~ l 2
if and only if h U l 2 = h. It is not hard to show that this in fact defines
a partial ordering and that h U h is the least upper bound (with respect to
~). A unit for the join operation is an element, _i, such that j_ U l = l. It is
not hard to show that the unit is in fact the least element (with respect to
~). It has been customary to demand that the property space, L, is a join
semi-lattice with a unit and that it satisfies the Ascending Chain Condition.
As proved in Lemma A.8 of Appendix A this is equivalent to our assumption
that the property space, L, is a complete lattice satisfying the Ascending
Chain Condition. •
Some formulations of Monotone Ftameworks are expressed in terms of prop-
erty spaces satisfying a Descending Chain Condition and using a combination
operator n. It follows from the principle of lattice duality (see the Cond ud-
ing Remarks of Chapter 4) that this does not change the notion of Monotone
Ftamework.
Transfer functions. Another important ingredient in the framework is

the set of transfer functions, fc : L __, L for C E Lab*. It is natural to demand
that each transfer function is monotone, i.e. l ~ l' implies fc(l) ~ fc(l').
Intuitively, this says that an increase in our knowledge about the input must
give rise to an increase in our knowledge about the output (or at the least
that we know the same as before). Formally, we shall see that monotonicity
is of importance for the algorithms we develop. To control the set of transfer
functions we demand that there is a set F of monotone functions over L,
fulfilling the following conditions:
• F contains all the transfer functions fc in question,
• F contains the identity function id, and
• F is closed under composition of functions.
The condition on the identity function is natural because of the skip state-
ment and the condition on composition of functions is natural because of
the sequencing of statements. Clearly one can take F to be the space of
monotone functions over L but it is occasionally advantageous to consider a
smaller set because it makes it easier to find compact representations of the
functions.
Some formulations of Monotone Ftameworks associate transfer functions with
edges (or flows) rather than nodes (or labels). A similar effect can be obtained
using the approach of Exercise 2.11.
Frameworks. In summary, a Monotone Framework consists of:
• a complete lattice, L, that satisfies the Ascending Chain Condition,

and we write U for the least upper bound operator; and
• a set F of monotone functions from L to L that contains the identity

function and that is closed under function composition.
Note that we do not demand that Fis a complete lattice or even a partially
ordered set although this is the case for the set of all monotone functions
from L to L (see Appendix A).
A somewhat stronger concept is that of a Distributive Framework. This is a
Monotone Ftamework where additionally all functions f in F are required to
be distributive:
f(h u h) = f(h) u f(h)
Since f(h U l 2 ) ;;:1 f(h) U f(l 2) follows from monotonicity, the only additional
demand is that f(h U l 2 ) ~ f(h) U f(l2)· When this condition is fulfilled it
is sometimes possible to get more efficient algorithms.
lnstances. The data flow equations make it clear that more than just
a Monotone (or Distributive) Ftamework is needed in order to specify an
analysis. To this end we define an instance, Analysis, of a Monotone (or
Distributive) Ftamework to consist of:
• the complete lattice, L, of the framework;
• the space of functions, F, of the framework;
• a finite fiow, F, that typically is fiow(S*) or fio~(S*);
• a finite set of so-called extrema[ labels, E, that typically is {init( S*)}

or final(S*);
• an extrema[ value, L E L, for the extremallabels; and
• a mapping, f., from the labels Lab* of F and E to transfer functions

in F.
The instance then gives rise to a set of equations, Analysis=, of the form
considered earlier:
Analysiso (f) U{Analysis.(.e') 1 (.e',C) E F} U L~
e { L_l iUE E
where Le = iUtf_E
Analysis. (f) = fe (Analysis f))
0 (
It also gives rise to a set of constraints, Analysis~, defined by:
Analysis0 ( f) ::J U{Analysis.(.e') 1 (.e',C) E F} U L~

iUE E
e
where Le ={ L
_l
iUtf_E
Analysis. (f) ::J fe (Analysis f))
0 (
Available Reaching Very Busy Live

Expressions Definitions Expressions Variables
L P(AExp*) P(Var* x Lab:) P(AExpJ P(Var*)

-c:: :>
- c- :>
- c-
u n u n u
j_ AExp* 0 AExp* 0
L 0 {(x, ?)lxEFV(S*)} 0 0
E { init(S*)} {init(S*)} final(S*) final(S*)
F flow(S*) flow(S*) flo~(S*) flo~(S*)
:F {!: L----> L 1 3lk, l9 : f(l) = (l \ lk) U l9 }

le fe(l) = (l \ kill([B]R)) U gen([B]i) where [B]R E blocks(S*)
Figure 2.6: Instances for the four classical analyses.
2.3.2 The Examples Revisited

We now return to the four classical analyses from Section 2.1 and show how
the analyses of a labei consistent program, S*, can be recast as an instance of
a Monotone (in fact Distributive) Framework. We refer to Figure 2.6 for ali
the data needed to specify the Monotone Framework as weli as the instance.
It is immediate that the property space, L, is a complete lattice in ali cases.
Given the choice of a partial ordering, !;;;;, the information about the least
element, 1_, and the least upper bound operation, U, is immediate. Note
that we define !;;;; tobe ~ for those analyses where we used U (and required
the least solution) in Section 2.1, and similarly, that we define !;;;; to be 2
for those analyses where we used n
(and required the greatest solution) in
Section 2.1. To ensure that L satisfies the Ascending Chain Condition we have
restricted our attention to the finite sets of expressions, labels and variables
occurring in the program, s*, under consideration.
The definition of the fl.ow, F, is as one should expect: it is flow( S*) for forward
analyses and flo~(S*) for backward analyses. Similarly, the extremallabels,
E are {init(S*)} for forward analyses and finaJ(S*) for backward analyses.
The only thing to note about the extrema! value, t, is that there seems to be
no general pattern concerning how to define it: it is not always T L (nor is it
always l_L)·
It remains to show that the conditions on the set :F of transfer functions are
satisfied.
Lemma 2.25 Each ofthe four data fiow analyses in Figure 2.6 is a Mono-
tone Framework as well as a Distributive Framework. •
Proof To prove that the analyses are Monotone Frameworks we just have to
confirm that :F has the necessary properties:
The functions of :F are monotone: Assume that l ~ l'. Then (l \ lk) ~ (l' \ lk)
and, therefore ((l \ h) U l9 ) ~ ((l' \ lk) U l9 ) and thus f(l) ~ f(l') as required.
Note that this calculation is valid regardless of whether ~ is ~ or ;:2.
The identity function is in :F: It is obtained by taking both lk and l9 to be 0.
The functions of :F are closed under composition: Suppose f(l) = (l \ lk) U l9 and
f'(l) = (l \ lU U l~. Then we calculate:
(f o f')(l) (((l \ l~) u l~) \ lk) u lg

(l \ (l~ u lk)) u {{l~ \ lk) u lg)
So (f o f')(l) = (l \ l~) U l~ where l~ = l~ U lk and l~ = (l~ \ lk) U l9 • This

completes the proof of the first part of the lemma.
To prove that the analyses are Distributive Frameworks consider f E :F given by
f(l) = (l \ lk) U l9 • Then we have:
f(l u l') ((l u l') \ lk) u lg

((l \ lk) u (l' \ lk)) u lg
((l \ lk) u lg) u ((l' \ lk) u lg)
f(l) u f(l')
Note that the above calculation is valid regardless of whether U is U or n. This

completes the proof. •
It is worth pointing out that in order to get this result we have made the
frameworks dependent upon the actual program - this is needed to enforce
that the Ascending Chain Condition is fulfilled.
Example 2. 26 Let us return to the Available Expressions Analysis of the

program
of Examples 2.4 and 2.5 and let us specify it as an instance of the associated
Monotone Framework. The complete lattice of interest is
(P( { a+b, a*b, a+1} ), ;;;?)
with least element {a+b, a*b, a+1 }. The set of transfer functions has the form
shown in Figure 2.6.
The instance of the framework additionally has the fiow { (1, 2), (2, 3), (3, 4),
(4, 5), (5, 3)} and the set of extremallabels is {1 }. The extrema} value is 0
and the transfer functions associated with the labels are
JtE(Y) YU {a+b}
f~E(Y) Y U {a*b}
J:E(Y) Y U {a+b}
JtE(Y) Y \ {a+b, a*b, a+1}
JtE(Y) Y U {a+b}
for Y ~ {a+b, a*b, a+1 }. •

2.3.3 A Non-distributive Example
Lest the reader should imagine that all Monotone Frameworks are Distribu-
tive Frameworks, here we present one that is not. The Constant Propagation
Analysis will determine:
For each program point, whether or not a variable has a constant

value whenever execution reaches that point.
Such information can be used as the hasis for an optimisation known as

Constant Folding: all uses of the variable may be replaced by the constant
value.
The Constant Propagation framework. The complete lattice

used for Constant Propagation Analysis of a program, S*, is
-
Statecp =((Var*---+ Z T )J_, ~, u, n, ..L, >.x.T)
where Var* is the set ofvariables appearing in the program and zT = ZU{T}
is partially ordered as follows:
\fz E zT: z ~ T
'tfzt, Z2 E Z : (zl ~ Z2) <=? (zl = Z2)
The top element of zT is used to indicate that a variable is non-constant and
all other elements indicate that the value is that particular constant. The
idea is that an element â of Var* ---+ zT is a property state: for each variable
x, â(x) will give information about whether or not x is a constant and in the
latter case which constant.
To capture the case where no information is available we extend Var*---+ zT
with a least element ..L, written (Var* ---+ zT)J_. The partial ordering ~ on
Statecp =(Var*---+ zT)J_ is defined by
VâE(Var*-+ZT)J_: ..L~â
\fâ1,â2 E Var*---+ zT: â1 ~ â2 iff 'Vx: â1(x) ~ â2(x)
AcP : AExp ~ (SÎaiecp ~ ZD

Acp[x]â { .1 ifâ=..l
â(x) otherwise
Acp[n]â {~ ifâ=..l
otherwise
transfer functions: Jj-P
[x :=a(: fip(â) { â[x

.1
t--7 Acp[a]â]
ifâ=..l
otherwise
[skip]": Jj-P(â) a
~
[b]": Jj-P(â) a
Table 2. 7: Constant Propagation Analysis.
and the binary least upper bound operation is then:

Vâ E (Var* ~ zT)J_ : â U .1 = â = .1 U â
Vâ1,â2 E Var*~ zT: Vx: (â1 U â2)(x) = â1(x) U â2(x)
In contrast to the earlier examples, we define the transfer functions as follows:
Fcp = {! 1 f is a monotone function on SÎaiecp}
It is easy to verify that SÎaiecp and Fcp satisfy the requirements of being a
Monotone Framework (see Exercise 2.8).
Constant Propagation is a forward analysis, so for the program S* we take
the fl.ow, F, to be Bow(S*), the extremal labels, E, to be {init(S*)}, the
extrema! value, iCP, to be Ax. T, and the mapping, f.CP, of labels to transfer
functions is given in Table 2.7. The specification of the transfer functions
uses the function
-
AcP : AExp ~ (Statecp ~ ZT _d
for analysing expressions. Here the operations on Z are lifted to = ZI
Z U {.1, T} by taking Zl opa Z2 = Zl OPa Z2 if ZI, Z2 E Z (and where OPa is
the corresponding arithmetic operation on Z), z1 <>Pa z2 = .1 if z1 = .1 or
z2 = .1 and Z1 <>Pa z2 = T otherwise.
Lemma 2.27 Constant Propagation is a Monotone Framework that is not

a Distributive Framework. •
Proof The proof that Constant Propagation is a Monotone Framework is left for
Exercise 2.8. To show that it is not a Distributive Framework consider the transfer
function f~P for [y:=x•x] 1 and let 0'1 and 0'2 be such that â'1(x) = 1 and â'2(x) = -1.
Then 0'1 U 0'2 maps x to T and thus f~P (0'1 U 0'2) maps y to T and hence fails to
record that y has the constant value 1. However, both ffP(â'I) and f~P(â'2) map y
to 1 and so does !? (0'1) U ffP (0'2). •
Correctness of the analysis will be established in Section 4.5.
2.4 Equation Solving

Having set up a framework, there remains the question of how to use the
framework to obtain an analysis result. In this section we shall consider two
approaches. One is an iterative algorithm in the spirit of Chaotic Iteration
as presented in Section 1.7. The other more directly propagates analysis
information along paths in the program.
2.4.1 The MFP Solution

We first present a general iterative algorithm for Monotone Frameworks that
computes the least solution to the data f:low equations. Historically, this
is called the MFP solution (for Maximal Fixed Point) although it in fact
computes the least fixed point; the reason is that the classical literature
tends to focus on analyses where U is n (and because the least fixed point
with respect to ~ or ;2 then equals the greatest fixed point with respect to
<;).
The algorithm, written in pseudo-cade in Table 2.8, takes as input an instance
of a Monotone Framework. It uses an array, Analysis, which contains the
Analysis0 information for each elementary block; the array is indexed by
labels. It also uses a worklist W which is a list of pairs; each pair is an element
of the f:low relation F. The presence of a pair in the worklist indicates that
the analysis has changed at the exit of (or entry to - for backward analyses)
the block labelled by the first component and so must be recomputed at the
entry to (or exit from) the block labelled by the second component. As a
final stage the algorithm presents the result (MFPa, MFP.) of the analysis
in a form clase to the formulation of the data f:low equations.
Example 2.28 To illustrate how the algorithms works let us return to

Example 2.26 where we consider the program
[x:=a+b]\ [y:=a•b] 2 ;while [y>a+b] 3 do ([a:=a+1] 4 ; [x:=a+b] 5 )
Writing W for the list ((2,3),(3,4),(4,5),(5,3)) and U for the set {a+b, a*b,
a+1 }, step 1 of the algorithm will initialise the data structures as in the
first row in Table 2.9. Step 2 will inspect the first element of the worklist
2.4 Equation Solving 75
INPUT: An instance of a Monotone Framework:

(L, :F, F, E, L, f.)
OUTPUT: MFPo, MFP.
METHOD: Step 1: Initialisation (of W and Analysis)
W:=nil;
for ali (i, i') in F do
W := cons((i,l'),W);
for ali i in F or E do
if i E E then Analysis[i] := L
else Analysis[i] := ..LL;
Step 2: Iteration (updating W and Analysis)
while W =1 nil do
i := fst{head{W)); i' = snd{head{W));
W := taii{W);
if h{Analysis[i]) [;?; Analysis[i'] then
Analysis[i'] := Analysis[i'] U h{Analysis[i]);
for ali i" with (i', i") in F do
W := cons((i',i"),W);
Step 3: Presenting the result (MFPo and MFP.)
for ali i in F or E do
MFPo(i) := Analysis[i];
MFP.(i) := ft{Analysis[i])
Table 2.8: Algorithm for solving data flow equations.
and rows 2-7 represent cases where there is a change in the array Analysis
and hence a new pair is placed on top of the worklist; it is inspected in the
next iteration. Rows 8-12 represent cases where no modification is made in
the array and hence the worklist is getting smaller - the elements of W are
merely inspected. Step 3 will then produce the solution we already saw in
Example 2.5. •
Properties of the algorithm. We shall first show that the algorithm

computes the expected solution to the equation system.
Lemma 2.29 The worklist algorithm in Table 2.8 always terminates and
it computes the least (or MFP) solution to the instance of the framework
given as input. •
Proof First we prove the termination result. Step 1 and 3 are bounded loops over
finite sets and thus trivially terminate. Next consider step 2. Assume that there
Analysis[t'] for f being

w 1 2 3 4 5
1 ((1,2),W) 0 u u u u
2 ((2,3),W) 0 {a+b} u u u
3 ((3,4),W) 0 {a+b} {a+b,a*b} u u
4 ((4,5),W) 0 {a+b} {a+b,a*b} {a+b,a*b} u
5 ((5,3),W) 0 {a+b} {a+b,a*b} {a+b,a*b} 0
6 ((3,4),W) 0 {a+b} {a+b} {a+b,a*b} 0
7 ((4,5),W) 0 {a+b} {a+b} {a+b} 0
8 ((2,3), .. ·) 0 {a+b} {a+b} {a+b} 0
9 ((3,4), .. ·) 0 {a+b} {a+b} {a+b} 0
10 ((4,5),·. ·) 0 {a+b} {a+b} {a+b} 0
11 ((5,3)) 0 {a+b} {a+b} {a+b} 0
12 o 0 {a+b} {a+b} {a+b} 0
Table 2.9: Iteration steps of the worklist algorithm.
are b labels in the program. Then the worklist initially has at most b2 elements;
the worst case is that F associates every label to every labei. Each iteration either
deletes an element from the worklist or adds up to b new elements. New elements
are added if for the pair selected in this iteration, (.e, f'), we have fe(Analysis[f]) !l
Analysis[f']; that is, fe(Analysis[.e]) :::J Analysis[f'] or they are incomparable. In either
case, the new value of Analysis[.e'] is strictly greater than the previous one. Since
the set of values satisfies the Ascending Chain Condition, this can only happen a
finite number of times. Thus the worklist will eventually be exhausted.
Next we prove the correctness result. Let Analysis0 and Analysis. be the least
solution to the instance given as input to the algorithm. The proof is now in three
parts: (i) first we show that on each iteration the values in Analysis are approxi-
mations to the corresponding values of Analysis0 , (ii) then we show that Analysis0
is an approximation to Analysis at the termination of step 2 of the algorithm, and
(iii) finally we combine these results.
Part (i). We show that
v.e: Analysis[.e] [;;; Analysis 0 (f)
is an invariant of the loop of step 2. After step 1 we have Analysis[f] [;;; Analysis0 (f)
for allf because Analysis0 (f);;;) L whenever .eE E. After each iteration through the
loop either there is no change because the iteration just deletes an element from
the worklist or else Analysis[.e"] is unchanged for all .e" except for some .e'. In that
case there is some .e such that (.e, f') E F and
newAnalysis[.e'] oldAnalysis[.e'] U fe( oldAnalysis[.e])

[;;; Analysis0 (f') U fe(Analysis 0 (f))
Analysis0 (.e')
The inequality follows since fe is monotone and the last equation follows from
(Analysis 0 , Analysis.) being a solution to the instance.
Part (ii). On termination of the loop, the worklist is empty. We show that
W,f': (f,f') E F => Analysis[f'J ;;;;) fe(Analysis[f])
by contradiction. So suppose that Analysis[.e'J i1 fe(Analysis[f]) for some (f, .e') E

F and let us obtain a contradiction. Consider the last time that Analysis[f] was
updated. If this was in step 1 we considered (f,f') in step 2 and ensured that
Analysis[f'] ;;;;) fe(Analysis[f])
and this invariant has been maintained ever since; hence this case cannot apply.
It follows that Analysis[f] was last updated in step 2. But at that time (f, .e') was
placed in the worklist once again. When considering (f, .e') in step 2 we then ensured
that
Analysis[f'] ;;;;) fe(Analysis[f])
and this invariant has been maintained ever since; hence this case cannot apply
either. This completes the proof by contradiction.
On termination of the loop we have:
W EE: Analysis[f];;;;) ~
This follows because it was established in step 1 and it is maintained ever since.
Thus it follows that at termination of step 2:
W: Analysis[f] ;;;;) (U{fe' (Analysis[f']) 1 (f', f) E F}) U ~~
Part (iii). By our assumptions and Proposition A.lO we have
W : MFP o ( f) ;;;;) Analysis0 ( f)
since Analysis0 (f) is the least solution to the above constraint system and MFPa
equals the final value of Analysis. Together with part (i) this proves that
W: MFPa[f] = Analysis (f)0
upon termination of step 2. •

Based on the proof of termination in Lemma 2.29 we can determine an upper
bound on the number of basic operations (for example an application of h,
an application of U, or an update of Analysis) performed by the algorithm.
For this we shall assume that the fl.ow F is represented in such a way (for
example an array of lists) that all (1!', l") emanating from i' can be found in
time proportional to their number. Suppose that E and F contain at most
b 2: 1 distinct labels, that F contains at most e 2: b pairs, and that L has
finite height at most h 2: 1. Then steps 1 and 3 perform at most O(b + e)
basic operations. Concerning step 2 a pair is placed on the worklist at most
O(h) times, and each time it takes only a constant number of basic steps to
process it- not counting the time needed to add new pairs to W; this yields
at most O(e · h) basic operations for step 2. Since h 2:: 1 and e 2:: b this
gives at most O(e · h) basic operations for the algorithm. (Since e :::; b2 a
potentially coarser bound is O(b2 • h).)
Example 2.30 Consider the Reaching Definitions Analysis and suppose

that there are at most V 2:: 1 variables and b 2:: 1 labels in the program, 8*,
being analysed. Since L = P(Var* x Lab:), it follows that h :S v · b and thus
we have an O(v · b3 ) upper bound on the number of basic operations.
Actually we can do better. If S* is labei consistent then the variable of the
pairs (x,l) of P(Var* x Lab:) will always be uniquely determined by the
labell so we get an O(b3 ) upper bound on the number of basic operations.
Furthermore, F is flow( S*) and inspection of the equations for flow( S*) shows
that for each labei l we construct at most two pairs with l in the first com-
ponent. This means that e :S 2 · b and we get an O(b2 ) upper bound on the
number of basic operations. •
2.4.2 The MOP Solution

Let us now consider the other solution method for Monotone Frameworks
where we more directly propagate analysis information along paths in the
program. Historically, this is called the MOP solution (for Meet Over all
Paths) although we do in fact take the join (or least upper bound) over
all paths leading to an elementary block; once again the reason is that the
classicalliterature tends to focus on analyses where U is n.
Paths. For the moment, we adopt the informal notion of a path to the
entry of a block as the list of blocks traversed from the start of the program
up to that block (but not including it); analogously, we can define a path
from an exit of the block. Data Flow Analyses determine properties of such
paths. Forward analyses concern paths from the initial block to the entry
of a block; backward analyses concern paths from the exit of a block to a
final block. The effect of a path on the state can be computed by composing
the transfer functions associated with the individual blocks in the path. In
the forward case we collect information about the state of affairs before the
block is executed and in the backward case we collect information about the
state of affairs immediately after the block has been executed. This informal
description contrasts with the approach taken in Section 2.1 and earlier in
this section; there we presented equations which were defined in terms of the
immediate predecessors (successors) of a block (as defined by the flow and
flo~ functions). We will see later that, for a large class of analyses, these
two approaches coincide.
For the formal development let us consider an instance (L, F, F, E, t, f.) of
a Monotone Framework. We shall use the notation l = [l1, · · ·, ln] for a
sequence of n 2: O labels. We then define two sets of paths. The paths up to

but not including C are
and the paths up to and including C are:
For a path l = [C 1 , · · · , Cn] we define the transfer function
Jc = Jcn O • •• O fRt O id
so that for the empty path we have fr J = id where id is the identity function.
By analogy with the definition of solutions to the equation system, in par-
ticular MFPa(C) and MFP.(C), we now define two components of the MOP
solution. The solution up to but not including C is
and the solution up to and including C is:
MOP.(C) = UUf(t) Il E path.(C)}

Unfortunately, the MOP solution is sometimes uncomputable (meaning that
it is undecidable) even though the MFP solution is always easily computable
(because of the property space satisfying the Ascending Chain Condition);
the following result establishes one such result:
Lemma 2.31 The MOP solution for Constant Propagation is undecid-

able. •
Proof Let u1, ···,Un and v1, · · ·, Vn be strings over the alphabet {1,· · ·,9} (see Ap-
pendix C). The Modified Post Correspondence Problem is to determine whether or
not there exists a sequence i1, · · ·, irn with i1 = 1 such that Ui 1 · · · Uim = Vi 1 ···Vin.
Let 1 u 1 denote the length of the string u and let [u] be its value interpreted as a
natural number. Consider the program (omitting most labels)
x:=[u!]; y:=[v!];
while [···]do
(if [· · ·] then x:=x * 10lu 1 1 + [u!]; y:=y * tolv,l + [v!] else
i f [· · ·] then x:=x * tolunl +[un]; y:=y * tolvnl + [vn] else skip)

[z: =sign( (x-y)*(x-y) )]c
where sign gives the sign (which is 1 for a positive argument and Oor -1 otherwise)
and where the details of[···] are of no concern to us.
Then MOP.(P) will map z to 1 if and only if the Modified Post Correspondence
Problem has no solution. Since the Modified Post Correspondence problem is un-
decidable [76] so is the MOP solution for Constant Propagation (assuming that our
selection of arithmetic operations does indeed allow those used tobe defined). •
MOP versus MFP solutions. We shall shortly prove that the MFP
solution safely approximates the MOP solution (informally, MFP ;::;;) MOP).
In the case of a (n, --t, i) or (n, +--, i) analysis, the MFP solution is a subset of
the MOP solution (;::;;J is s;;); in the case of a (U, --t, !) or (U, +--, !) analysis,
the MFP solution is a superset of the MOP solution. We can also show
that, in the case of Distributive Frameworks, the MOP and MFP solutions
coincide.
Lemma 2.32 Consider the MFP and MOP solutions to an instance (L, :F,
F, B, t, f.) of a Monotone Framework; then:
MFPo ;::;;) MOPo and MFP. ;::;;) MOP.
lf the framework is distributive and if path0 ( l) =/:- 0 for all l in E and F then:
MFPo = MOPo and MFP. = MOP.
•
Proof It is straightforward to show that:
Vf: MOP.(P) !: ft(MOPa(P))

Vf: MFP.(f) = ft(MFPa(.e))
For the first part of the lemma it therefore suffices to prove that:
Vf: MOPa(P) !: MFPa(P)
Note that MFPa is the least fixed point of the functional F defined by:
F(Ao)(f) = (U{ft' (Ao(.e')) 1 (.e', f) E F}) U L~
Next let us restrict the length of the paths used to compute MOPa; for n ~ O
define:
MOPo(P) = U{fj{t) 1f E patho(P), lfl < n}
Clearly, MOPa(P) =Un MOPo(f) and to prove MFPa;;;) MOPa is therefore suffices
to prove
Vn: MFPa;;;) MOPo
and we do so by numerica! induction. The hasis, MFPa ;;;) MO~, is trivial. The
inductive step proceeds as follows:
MFPa(P) = F(MFPa)(f)
(u{ff (MFPo(C')) 1 (/!',/!)

1 E F}) U ~~
::J (U{fe(MOF;,'(I!')) (1!',1!) E F}) u ~~

1
(U{fe(U{fe(~) fE path 0 (1!'), lfl < n}) (1!',1!) E F})

1 1 U ~~
::J (u({UUdfe(~)) 1 i E patho(C'), lil < n} (1!',1!) 1 E F}) u ~~
U({fe(~) 1 f E path 0 (1!), 1 ~ lfl ~ n}) U ~~

MOP~+l(f!)
where we have used the induction hypothesis to get the first inequality. This com-
pletes the proof of MFPo ;;;) MOPo and MFP. ;;;) MOP•.
To prove the second part of the lemma we now assume that the framework is
distributive. Consider 1! in E or F. By assumption h is distributive, that is
!f(l 1 U l2) = !f(l 1 ) U h(l2), and from Lemma A.9 of Appendix A it follows that
whenever Y is non-empty. By assumption we also have path 0 (1!) -j. 0 and it follows
that
U{JE(fe(~)) 1 f E path 0 (1!)}
UUe( ~) i 1 E path. (!!)}
and this shows that:

VI!: fE(MOPo(f)) = MOP.(I!)
Next we calculate:
MOPo(f) Uue<~) 1 i E patho(l!)}
u{ff{~) 1fE u{path.(f!') 1(1!',1!) E F} U {(]il! EE}}
U({Jf'(ff{~)) 1f E path 0 (1!'), (1!',1!) E F} U {~li! EE})
(u{ff'(u{ff{~) 1 f E patho(f!')} 1 (/!', 1!) E F}) U ~~
(u{ff'(MOPo(l!')) 1(/!', 1!) E F}) u ~~

Together this shows that (MOPo, MOP.) is a solution to the data flow equations.
Using Proposition A.lO of Appendix A and the fact that (MFPo, MFP.) is the least
solution we get MOPo;;;) MFPo and MOP. ;;;) MFP•. Together with the results of
the first part of the lemma we get MOPo = MFPo and MOP. = MFP.. •
We shallleave it to Exercise 2.13 to show that the condition that path 0 (R) =/= 0
(for Rin E and F) does hold when the Monotone Framework is constructed
from a program S* in the manner of the earlier sections.
It is sometimes stated that the MOP solution is the desired solution and
that one only uses the MFP solution because the MOP solution might not be
computable. In order to validate this belief we would need to prove that the
MOP solution is semantically correct as was proved for the MFP solution in
Section 2.2 in the case of Live Variables Analysis- in the case of Live Variables
this is of course immediate since it is a Distributive Framework. We shall not
do so because it is always possible to formulate the MOP solution as an MFP
solution over a different property space (like P(L)) and therefore little is lost
by focusing on the fixed point approach to Monotone Frameworks. (Also
note that P(L) satisfies the Ascending Chain Condition when Lis finite.)
2.5 Interprocedural Analysis

The Data Flow Analysis techniques that have been presented in the previous
sections are called intraprocedural analyses because they deal with simple
languages without functions or procedures. It is somewhat more demand-
ing to perform interprocedural analyses where functions and procedures are
taken into account. Complications arise when ensuring that calls and returns
match one another, when dealing with parameter mechanisms (and the alias-
ing that may result from call-by-reference) and when allowing procedures as
parameters.
In this section we shall introduce some of the key techniques of interproce-
dural analysis. To keep things simple we just extend the WHILE language
with top-level declarations of global mutually recursive procedures having a
call-by-value parameter and a call-by-result parameter. The extension of the
techniques to a language where procedures may have multiple call-by-value,
call-by-result and call-by-value-result parameters is straightforward and so
is the extension with local variable declarations (see Exercise 2.20); we shall
freely use these extensions in examples.
Syntax of the procedure language. A program, P*, in the ex-

tended WHILE-language has the form
begin D* S* end
where D* is a sequence of procedure declarations:
D ::= proc p(val x, res y) is"n S end""' 1 D D
Procedure names (denoted p) are syntactically distinct from variables (de-
noted x and y). The labelln of is marks the entry to the procedure body
and the labellx of end marks the exit from the procedure body. The syntax
of statements is extended with:
S ::= · · · 1 [call p(a, z)]~~
The call statement has two labels: le will be used for the call of the procedure
and lr will be used for the associated return; the actual parameters are a
and z.
2.5 Interprocedural Analysis 83
The language is statically scoped, the parameter mechanism is call-by-value

for the first parameter and call-by-result for the second parameter and the
procedures may be mutually recursive. We shall assume throughout that
the program is uniquely labelled (and hence label consistent); also we shall
assume that only procedures that have been declared inD* are ever called
and that D* does not contain two definitions of the same procedure name.
Example 2.33 Consider the following program calculating the Fibonacci

number of the positive integer stored in x and returning it in y:
begin proc fib(val z, u, res v) is 1

i f [z<3j2 then [v:=u+1j3
else ([call fib(z-1,u,v)]~; [call fib(z-2,v,v)]~)
end8 ;
[call fib(x,O,y)]Io
end
It uses the procedure fib that returns in v the Fibonacci number of z plus
the value of u. Both x and y are global variables whereas z, u and v are
formal parameters and hence local variables. •
Flow graphs for statements. The next step is to extend the defi-
nitions of the functions init, final, blocks, labels, and flow to specify the flow
graphs also for the procedure language. For the new statement we take:
init([call p(a, z)]~~)

final([call p(a, z)]~~) {fir}
blocks([call p(a, z)]~~) {[call p(a, z)]~~}
labels([call p(a, z)]~~) {ie,lr}
flow([call p(a, z)]~~) {(ie;ln),(ix;lr)}
if proc p(val x, res y) isRn S endR"'
is inD*
Here (le; in) and (ix; lr) are new kinds of flows:
• (le; in) is the flow corresponding to calling a procedure at le and with

in being the entry point for the procedure body, and
• (ix; lr) is the flow corresponding to exiting a procedure body at ix and
returning to the call at lr.
The definition of flow([call p(a, z)]~~) exploits the fact that the syntax of
procedure calls only allows us to use the (constant) name of a procedure
defined in the program; had we been allowed to use a variable that denotes
a procedure (e.g. because it was a formal parameter to some procedure or
because it was a variable being assigned some procedure) then it would be
much harder to define f:low([call p(a, z)]~~). This is often called the dynamic
dispatch problem and we shall deal with it in Chapter 3.
Flow graphs for programs. Next consider the program P* of the

form begin D* S* end. For each procedure declaration proc p(val x, res y)
isln S endlx we set
init(p) fn
final(p) {fx}
blocks(p) { isln, endfx} U blocks(S)
labels(p) {in, fx} U labels(S)
flow(p) = {(in, init(S))} U flow(S) U { (f, fx) 1 f E final(S)}
and for the entire program P* we set
init* init( s*)

final* = final( s*)
block~ U{blocks(p) 1 proc p(val x, res y) isln S endlx is inD*}
U blocks(S*)
labels* U{labels(p) 1 proc p(val x,res y) is'n S endlx is inD*}
u labels( s*)
flow* = U{flow(p) 1 proc p(val x,res y) isln S endtx is inD*}
U flow(S*)
as well as Lab* = labels*.

We shall also need to define a notion of interprocedural ftow
inter-flow* = {(fc,fn,fx,fr) 1 P* contains [callp(a,z)]~~

as well as proc p(val x, res y) isln S endlx}
that clearly indicates the relationship between the labels of a procedure call
and the corresponding procedure body. This information will be used later to
analyse procedure calls and returns more precisely than is otherwise possible.
Indeed, suppose that inter-flow* contains (f~, ln, fx, f~) for i = 1, 2 in which
case f:low* contains (f~; ln) and (fx; f~) for i = 1, 2. But this "gives rise to"
the four tuples (f~, fn, fx, it) for i = 1, 2 and j = 1, 2 and only the tuples
with i = j match the return with the call: these tuples are exactly the ones
in inter-flow*.
2.5 lnterprocedural Analysis 85
proc fib(val z, u, res v)
is 1
1 no
l
1 [z<3j2 1
!yes
!
-
1[call fib(x,O,y)]Îo 1 1[v:=u+1]31 1[call fib(z-1,u,v)Jgl: -
! !
1[call fib(z-2,v,v)J?I:
1
J,
end8
Figure 2. 7: Flow graph for the Fibonacci program.
Example 2.34 For the Fibonacci program considered in Example 2.33

we have
Bow* {(1, 2), (2, 3), (3, 8),

(2,4),(4;1),(8;5),(5,6),(6;1),(8;7),(7,8),
(9; 1 ), (8; 10)}
inter-Bow* = {(9,1,8,10),(4,1,8,5),(6,1,8,7)}
and init* = 9 and final* = {10}. The corresponding flow graph is illustrated
in Figure 2.7. •
For a forward analysis we use F = Bow* and E = {init*} much as before

and we introduce a new "metavariable" IF = inter-Bow* for the interpro-
cedural flow; for a backward analysis we use F = Ho~, E = final* and
IF = inter-Bo~. Most of the explanations in the sequel will focus on for-
ward analyses.

We shall now show how the semantics of WHILE can be extended to cope
with the new constructs. To ensure that the language allows local data in
procedures we shall need to distinguish between the values assigned to dif-

ferent incarnations of the same variable and for this we introduce an infinite
set of locations (or addresses):
~ E Loc locations
An environment, p, will map the variables in the current scope to their loca-
tions, and a stare, .,-, will then specify the values of these locations:
p E Env Var* ---+ Loc environments

c; E Store Loc --+fin Z stores
Here Var* is the (finite) set of variables occurring in the program and
Loc --+fin Z denotes the set of partial functions from Loc to Z that have
a finite domain. Thus the previously used states a E State = Var* ---+ Z
have been replaced by the two mappings p and c; and can be reconstructed
as a = c; o p: to determine the value of a variable x we first determine its
location ~ = p(x) and next the value c;(~) stored in that location. For this
to work it is essential that c; o p : Var* ---+ Z is a total function rather than
a partial function; in other words, we demand that ran(p) <;;; dom( c;) where
ran(p) = {p(x) 1 x E Var*} and dom(c;) = {~ l<> is defined onO.
The locations of the global variables of the program P* are given by a top-level
environment denoted p*; we shall assume that it maps all variables to unique
locations. The semantics of statements is now given relative to modifications
of this environment. The transitions have the general form
p f- * (S, c;) ---+ (S', c;')
in case that the computation does not terminate in one step, and the form
in case that it does terminate in one step. It is fairly straightforward to

rewrite the semantics of WHILE given in Table 2.6 to have this form; as an
example the clause [ass] for assignments becomes:
Note that there is no need to modify the semantics of arithmetic and boolean
expressions.
For procedure calls we make use of the top-level environment, p*, and we
take:
p f- * ([call p(a, z)]~~, ~) ~

(bind p*[x f-+ 6, y f-+ 6] in S then z: =y, ~[6 f-+ A[a](~ o p), 6 f-+ v])
where 6,6 rţ dom(~),v E Z
and proc p(val x, res y) isln S endlx is inD*
The idea is that we allocate new locations 6 and 6 for the formal parameters
x and y, and we then make use of a bind-construct to combine the procedure
body S with the environment p*[x f-+ 6, y f-+ 6] in which it must be executed
and we also record that the final value of y must be returned in the actual
parameter z. At the same time the store is updated such that the new location
for x is mapped to the value of the actual parameter a whereas we do not
control the initial value, v, of the new location for y. The bind-construct is
only needed to ensure that we have static scope rules and its semantics is as
follows:
p f- * (bind p' in S then z: =y, ~) ~ (bind p' in S' then z: =y, ~')
p f- * (bind p' inS then z: =y, ~) ~ ~'[p(z) f-+ ~'(p'(y))]
The first rule expresses that executing one step of the body of the construct
amounts to executing one step of the construct itself; note that we use the
local environment when executing the body. The second rule expresses that
when the execution of the body finishes then so does execution of the con-
struct itself and we update the value of the global variable z to be that of the
local variable y; furthermore, there is no need for the local environment p' to
be retained as subsequent computations will use the previous environment p.
Remark. Although the semantics works with two mappings, an environ-
ment and a store, it is often the case that the analysis abstracts the state,
i.e. the composition of the environment and the store. The correctness of the
analysis will then have to relate the abstract state both to the environment
and the store.
The correctness result will often be expressed in the style of Section 2.2:
information obtained by analysing the original program will remain correct
under execution of the program. The semantics presented above deviates
from that of the WHILE-language in that it introduces the bind-construct
which is only used in the intermediate configurations. So in order to prove
the correctness result we will also need to specify how to analyse the bind-
construct. We refer to Chapter 3 for an illustration of how to do this. •
2.5.2 Intraprocedural versus Interprocedural Analysis
To appreciate why interprocedural analysis is harder than intraprocedural

analysis let us begin by just naively using the techniques from the previous
sections. For this we suppose that:
• for each procedure call (cal! p(a, z)]~~ we have two transfer functions
hc and hr corresponding to calling the procedure and returning from
the call, and
• for each procedure definition proc p(val x, res y) is"n S end"" we

have two transfer functions hn and /f" corresponding to entering and
exiting the procedure body.
A naive formulation. Given an instance (L, :F, F, E, t, f.) of a Mono-

tone Framework we shall now treat the two kinds of flow ((ft,f2 ) versus
(fe; in) and (fx; lr)) in the same way: we interpret the semi-colon as stand-
ing for a comma. While a Monotone Framework is allowed to interpret all
transfer functions freely, we shall for now naively assume that the two trans-
fer functions associated with procedure definitions are the identity functions,
and that the two transfer functions associated with each procedure call are
also the identity functions, thus effectively ignoring the parameter-passing.
We now obtain an equation system of the form considered in the previous
sections:
A.(f) fp_(Ao(f))
Ao(f) U{A.(i') 1(f', f) E For (i'; f) E F} U t~
Here t~ is as in Section 2.3:
iUEE
iU fţ E
When inspecting this equation system is should be apparent that both proce-
dure calls (le; in) and procedure returns (ix; lr) are treated like goto's: there
is no mechanism for ensuring that information flowing along (le; in) from a
call to a procedure only flows back along (fx; lr) from the procedure to the
same call. (Indeed, nowhere does the formulation consult the interprocedu-
ral flow, IF.) Expressed in terms of the flow graph in Figure 2.7, there is
nothing preventing us from considering a path like (9, 1, 2, 4, 1, 2, 3, 8, 10) that
does not correspond to a run of the program. Intuitively, the equation system
considers a much too large set of "paths" through the program and hence
will be grossly imprecise (although formally on the safe side).
Valid paths. A natural way to overcome this shortcoming is to somehow

restrict the attention to paths that have the proper nesting of procedure calls
and exits. We shall explore this idea in the context of redefining the MOP
solution of Section 2.4 to only take the proper set of paths into account,
thereby defining an MVP solution (for Meet over all Valid Paths).
So consider a program P* of the form begin D* S* end. A path is said to be
a complete path from R1 to R2 in P* if it is has proper nesting of procedure
entries and exits and such that a procedure returns to the point where it was
called. These paths are generated by the nonterminal CPe 1 ,e 2 according to
the following productions:
CPR 1 ,f 2 ----+ R1 whenever R1 = R2

CPe 1 ,e3 ----+ R1, CPR 2 ,e3 whenever (R1,R2) E F;
for a forward analysis this means
that (R1,R2) E fiow*
CPec,t ----+Re, CPen,Rx, CPer,R whenever (Re, Rn, Rx, Rr) E IF;
for a forward analysis this means
that P* contains [call p(a, z)J~:
and proc p(val x, res y) isRn S endfx
The matching of calls and returns is ensured by the last kind of productions:
the flows (Re;Rn) and (Rx;Rr) are forced to obey a parenthesis structure in
that Re, Rn will be in the generated path only if there is a matching occur-
rence of Rx, Rr - and vice versa. Hen ce for a forward analysis, a terminating
computation will give rise to a complete path from init* to one of the labels
of final*. Note that the grammar constructed above will only have a finite
set of nonterminals because there is only a finite set of labels in P*.
Example 2.35 For the Fibonacci program of Example 2.33 we obtain the
following grammar (using forward flow and ignoring the parts not reachable
from CP9,10):
CP9,1o ----7 9, CP1,s, CP10,10 CP3,s ----7 3, CPs,s

CPlO,lO ----7 10 CPs,s ----7 8
CP1,s ----7 1, CP2,s CP4,s ----7 4, CPl,S, CP5,8
CP2,s ----7 2, CP3,s CP5,s ----7 5, CP6,s
CP2,s ----7 2, CP4,s CP6,s ----7 6, CP1,s, CP1,s
CP1,s ----7 7, CPs,s
It is now easy to verify that the path [9, 1, 2, 4, 1, 2, 3, 8, 5, 6, 1, 2, 3, 8, 7, 8, 10]

is generated by CP9,10 whereas the path [9, 1, 2, 4, 1, 2, 3, 8, 10] is not. •
A path is said to be a valid path if it starts at an extremal node of P* and
if all the procedure exits match the procedure entries but it is possible that
some procedures are entered but not yet exited. This will obviously include
all prefixes of the complete paths starting in E but we also have to take into
account prefixes of computations that might not terminate. To specify the
valid paths we therefore construct another grammar with productions:
VP* ----+ VPt 1 ,t2 whenever i1 EE and i2 E Lab*

VPt 1 ,t2 ----+ i1 whenever i1 = i2
VPt1,t 3 ----+ i~, VPt 2 ,t3 whenever (i~, i2) E F
VPtc,t ----+ ic, CPtn,lx, VPtr,t whenever (ic,in,ix,ir) E IF
VPtc,t ----+ ic, VPtn,l whenever (ic,in,ix,ir) E IF
The valid paths will then be generated by the nonterminal VP*. For a for-
ward analysis, to go from the labei ic of a procedure call to the program point
i there are two possibilities. One is that the call initiated at ic terminates
before reaching i and this corresponds to the second last kind of production
where we use the nonterminal CPtn,lx to generate the complete path corre-
sponding to executing the procedure body. The other possibility is that i
is reached before the call terminates and this corresponds to the last kind
of production where we simply use VPtn,l to generate a valid path in the
procedure body.
We can now modify the two sets of paths defined in Section 2.3 as follows
(keeping in mind that the definitions are implicitly parameterised on F, E
and IF):
vpath 0 (i) {[i~, · · ·, ln-l]i n 2: 1/\ ln = i 1\ [i1, ···,in] is a valid path}
vpath.(i) {[i1, · · ·, in]i n 2: 1/\ in = i 1\ [i1, ···,in] is a valid path}
Clearly the sets of paths are smaller than what would have resulted if we
had merely regarded (i 1; i2) as standing for (i 1, i2) and had used the notions
path0 (i) and path.(i) of Subsection 2.4.2.
Using valid paths we now define the MVP solution as follows:
MVPo(i) = UUf(t) il E vpath 0 (i)}
MVP.(i) = UUf(t) il E vpath.(i)}

Since the sets of paths are smaller than in the similar definitions in Subsection
2.4.2, we clearly have MVPo(i) ~ MOPo(i) and MVP.(i) ~ MOP.(i) for
all i.
2.5.3 Making Context Explicit

The MVP solution may be undecidable for lattices of finite height, just as was
the case for the MOP solution, so we now have to reconsider the MFP solution
and how to avoid taking too many invalid paths. An obvious approach is
to encode information about the paths taken into the data flow properties
themselves; to this end we introduce context information:
context information
The context may simply be an encoding of the path taken but we shall see
in Subsection 2.5.5 that there are other possibilities. We shall now show how
an instance of a Monotone Framework (as introduced in Section 2.3) can be
extended to take context into account.
The intraprocedural fragment. Consider an instance (L, F, F, E,

t, f.) of a Monotone Framework. We shall now construct an instance
(L, J, F, E, î, f)
of an embellished Monotone Framework that takes context into account. We

begin with the parts of its definition that are independent of the actual choice
of ~. i.e. the parts that correspond to the intraprocedural analysis:
• L = ~ - t L;
• the transfer functions in J are monotone; and
• each transfer function J; is given by J;(i)(8) = ft(l (8)).
In other words, the new instance applies the transfer functions ofthe original
instance in a pointwise fashion.
Ignoring procedures, the data flow equations will take the form displayed
earlier:
A.(f) h(Ao(f))
for alllabels that do not labei a procedure call
(i.e. that do not occur as first or fourth components
of a tuple in IF)
U{A.(f') 1(f',f) E For (f';f) E F} U 4

for alllabels (including those that labei procedure calls)
Example 2.36 Let (Lsign, Fsign, F, E, Lsign, pign) be an instance of a Mono-

tone Framework specifying a Detection of Signs Analysis (see Exercise 2.15)
and assume that
Lsign = P(Var* - t Sign)
where Sign = {-,O,+}. Thus Lsign describes sets of abstract states a•ign map-
ping variables to their possible signs. The transfer function J;ign associated
with the assignment [x :=a]" will now be written as
where Y ~ Var* ~ Sign and
if>~ign(asign) = {asign[x f-t s]l sE Asign[a](asign)}
Here Asign : AExp ~ (Var* ~ Sign) ~ P(Sign) specifies the analysis of

arithmetic expressions. The transfer functions for tests and skip-statements
are the identity functions.
Given a set ~ of contexts, the embellished Monotone Framework will have
L-;;;;, = ~ ~ Lsign
but we shall prefer the following isomorphic definition
L:;, = P(~ x (Var*~ Sign))
Thus f;;, describes sets of pairs of context and abstract states. The transfer
function associated with the assignment [x :=a]" will now be:
-
J;ign (Z) = UHo} x q;~ign(asign) 1 (o, asign) E Z}
In subsequent examples we shall further develop this analysis. •

The interprocedural fragment. It remains to formulate the data
flow equations corresponding to procedures.
For a procedure definition proc p(val x, res y) is"n S end""' we have two
transfer functions:
J;:, k: (~ ~ L) ~ (~ ~ L)
In the case of our simple language we shall prefer to take both of these transfer
functions to be the identity function; i.e.
-r;: (Î) ~
k(Î)
for all Î E i. Hence the effect of procedure entry is handled by the trans-
fer function for procedure call (considered below) and similarly the effect of
procedure exit is handled by the transfer function for procedure return (also
proc p(val x, res y)
[call p(a, z)]~~
Figure 2.8: Analysis of procedure call: the forward case.
considered below). For more advanced languages where many semantic ac-
tions take place at procedure entry or exit it may be preferable to reconsider
this decision.
For a procedure call (fc, fn, fx, fr) E IF we shall define two transfer functions.
In our explanation we shall concentrate on the case of forward analyses where
P* contains [call p(a, z)]~~ as well as proc p(val x, res y) isln S endix.
Corresponding to the actual call we have the transfer function
- : (~ ~ L) ~ (~ ~ L)
!L
and it is used in the equation:
In other words, the transfer function modifies the data flow properties (and
the context) as required for passing to the procedure entry.
Corresponding to the return we have the transfer function
and it is used in the equation:

~
A.(fr) = flc,tr (Ao(fc),Ao(fr)) for all (fc,fn,fx,fr) E IF

~
The first parameter of flc,tr describes the data flow properties at the call
point for the procedure and the second parameter describes the properties at
the exit from the procedure body. Ignoring the first parameter, the transfer
function modifies the data flow properties (and the context) as required for
passing back from the procedure exit. The purpose of the first parameter is
1 [call p(a, z)jic 1
1 [call p(a, z)]tr 1
Figure 2.9: Analysis of procedure call: ignoring calling context.
to recover some of the information (data flow properties as well as context

information) that was available before the actual call; how this is done de-
pends on the actual choice of the set, ~. of context information and we shall
return to this shortly. Figure 2.8 illustrates the flow of data in the analysis
of the procedure call.
Variations. The functionality and use of J[;r (as well as Figure 2.8) is
sufficiently general that it allows us to deal with most of the scenarios found
in the literature. A simple example being the possibility to define
thereby completely ignoring the information before the call; this is illustrated
in Figure 2.9.
A somewhat more interesting example is the ability to define
thereby allowing a simple combination of the information coming back from

the call with the information pertaining before the call. This form is illus-
trated in Figure 2.10 and is often motivated on the gr~ds that fff;r
copies
data that is local to the calling procedure whereas Jl 81!
c, r
copies information
---
that is global. (It may be worth noticing that the function JLI!r is com-
pletely additive if and only if it can be written in this form with
-
/[A;
c,r
and
fl!:tr being completely additive.)
Context-sensitive versus context-insensitive. So far we have
criticised the naive approach because it was unable to maintain the proper
1 [call p(a, z)Jtr 1
Figure 2.10: Analysis of procedure call: merging of context.
relationship between procedure calls and procedure returns. A related criti-

cism of the naive approach is that it cannot distinguish between the different
calls of a procedure. The information about calling states is combined for
all call sites, the procedure body is analysed only once using this combined
information, and the resulting information about the set of return states is
used at all return points. The phrase context-insensitive is often used to refer
to this shortcoming.
The use of non-trivial context information not only helps to avoid the first
criticism but also the second: if there are two different calls but they are
reached with different contexts, <hand 82, then all information obtained from
the procedure will be clearly related to <h or 82 and no undesired combination
or "cross-over" will take place. The phrase context-sensitive is often used to
refer to this ability.
Clearly a context-sensitive analysis is more precise than a context-insensitive
analysis but at the same time it is also likely to be more costly. The choice be-
tween which technique to use amounts to a careful balance between precision
and efficiency.
2.5.4 Call Strings as Context

To complete the design of the analysis of the program we must choose the set,
Â, of context information and also specify the extremal value, î, and define
the two transfer functions associated with procedure calls. In this subsection
we shall consider two approaches based on call strings and our explanation
will be in terms of forward analyses.
Call strings of unbounded length. As the first possibility we

simply encode the path taken; however, since our main interest is with pro-
cedure calls we shall only record flows of the form (fc; fn) corresponding to
a procedure call. Formally we take
~ = Lab*
where the most recent labei fc of a procedure call is at the right end (just as
was the case for valid paths and paths); elements of ~ are called call strings.
We then define the extremal value î by the formula
î( 8) = { L if 8 = A
..1. otherwise
where A is the empty sequence corresponding to the fact that there are no
pending procedure calls when the program starts execution; t is the extremal
value available from the underlying Monotone Framework.
Example 2.37 For the Fibonacci program of Example 2.33 the following
call strings will be of interest:
A, [9], [9, 4], [9, 6], [9, 4, 4], [9, 4, 6], [9, 6, 4], [9, 6, 6], · · ·
corresponding to the cases with O, 1, 2, 3, · · · pending procedure calls. •
For a procedure call (fc,fn,fx,fr) E IF, amounting to [call_!(a,z)]~~ in

the case of a forward analysis, we define the transfer function JL such that
Î[ (Î)([8,fc]) = JlJÎ(8)) where [8,fc] denotes the path obtained by append-
ing fc to 8 (so as to reflect that now we enter the body of the procedure)
and the function JL :L __. L describes how the property is modified. This is
achieved by setting
j1 (Î)(<5') = { JlJÎ(8)) when ~ 1 = [8,fc]

ic ..1. otherw1se
which takes care of the special case of empty paths.

Next we define the transfer function ff:;r corresponding to returning from
the procedure call:
2
f'Ltr
-- --
(l, l' )(8) = h,ir (l- (8), l'- ([8, fc]))
Here the information Î from the original call is combined with information fl
from the procedure exit using the function fl i : L x L __. L. However, only
information corresponding to the same conte:it; for call point fc is combined:
this is ensured by the two occurrences of 8 in the right hand side of the above
formula.
Example 2.38 Let us return to the Detection of Signs Analysis of Ex-

ample 2.36. For a procedure call [call p(a, z)]~~ where p is declared by
proc p(val x, res y) isfn S endfx we may take:
{asign[x f---7 s][y f---7 s']l sE Asign[a](asign) 1\ s' E {-,0,+}}

When returning from the procedure call we take:
Jt~~: (Z, Z') UH o} X cp~i;,~~ (a~ign' a~ign) 1 (o, a~ign) E z 1\
1\ (o',a~ign) E Z' 1\ o'= [o,Cc]}

cp~i;,~~(a~ign,a~ign) = {a~ign[x f---7 a~ign(x);y f---7 a~ign(y);z f---7 a~ign(y)]}
Thus we extract all the information from the procedure body except for the
information about the formal parameters x and y and the actual parameter
z. For the formal parameters we rely on the information available before the
current call which is still correct and for the actual parameter we perform the
required update of the information. ~e that to facilitate this definition it
is crucial that the transfer function Jl c takes two arguments: information
from the call point as well as from thec'p~ocedure exit. •
Call strings of bounded length. Clearly the call strings can be-
come arbitrarily long because the procedures may be recursive. It is therefore
customary to restrict their length to be at most k for some number k ~ O;
the idea being that only the last k calls are recorded. We write this as
~ = Lab:'=k
and we still take the extremal value î to be defined by the formula
î( o) = { L if o = A
j_ otherwise
Note that in the case k = O we have ~ = {A} which is equivalent to having
no context information.
Example 2.39 Consider the Fibonacci program of Example 2.33 and as-
sume that we are only interested in recording the last call, i.e. k = 1. Then
the call strings of interest are:
A, [9], [4], [6]

Alternatively, we may choose to record the last two calls, i.e. k = 2, in which
case the following call strings are of interest:
In general, we would expect an analysis using these 8 contexts to be more

precise than one using the 4 different contexts displayed above. •
We shall now present the transfer functions for the g~eral case where call
strings have length at most k. The transfer function for procedure call JL
is redefined by
ii (Î)(8') = UUfJÎ(8)) 18' = I8,Relk}

where 18, Re l k denotes the call string [8, Re] but possibly truncated (by omit-
ting elements on the left) so as to have length at most k. Since the function
mapping 8 to 18, Reh is not injective (unlike the one mapping 8 to [8, Re]) we
need to take the least upper bound over all 8 that can be mapped to the
relevant context 8'.
Similarly, the transfer function fl-e
c, r
for procedure return is redefined by
- -- 2 -- -
fLer (l, l' )(8) = h,eJl (8), l' ( 18, Re h))
as should be expected.
Example 2.40 Let us consider Detection of Signs Analysis in the special

case where k = O, i.e. where ~ = {A} and hence ~ x (Var* -+ Sign) is
isomorphic to Var* -+ Sign. Using this isomorphism the formulae defining
the transfer functions for procedure call can be simplified to
-
pign2
fc,P-r
(Y Y')
'
where Y, Y' ~ Var* -+ Sign. It is now easy to see that the analysis is context-
insensitive: at procedure return it is not possible to distinguish between the
different call points.
Let us next consider the case where k = 1. Here ~ = Lab U {A} and the
transfer functions for procedure call are:
tgn2
fc,l!-r
(Z, Z') u{{ 8} X <j>~i~,~~ ( O"~ign' O"~ign) 1 ( 8, O"~ign) E z
1\ (Re, O"~ign) E Z'}
-
Now the transfer function J;~gnl will mark all data from th~ll point Re with
that labei. Thus it does not harm that the information J;~gnl (Z) is merged
-
with similar information Jt~" 1 (Z) fro~nother procedure call. At the return
from the call the transfer function J;~~~~ selects those pairs (le, a~ign) E Z'
that are relevant for the current call and combines them with those pairs
(a, a~ign) E Z that describe the situation before the call; in particular, this
allows us to reset the context tobe that of the call point. •
2.5.5 Assumption Sets as Context

An alternative to describing a path directly in terms of the calls being per-
formed is to record information about the state in which the call was roade;
these methods can clearly be combined but in the interest of simplicity we
shall abstain from doing so.
Large assumption sets. Throughout this subsection we shall make

the simplifying assumption that
L = P(D)
as is the case for the Detection of Signs Analysis. Much as in Examples 2.36
and 2.38 the property space L =~--+Lis then isomorphic to
L = P(~ X D)
and we shall use this definition throughout this subsection. Restricting the
attention to only recording information about the last call (corresponding to
taking k = 1 above), one possibility is to take
~ = P(D)
and we then take the extrema! value to be
meaning that the initial context is described by the initial abstract state. This
kind of context information is often called an assumption set and expresses
a dependency on data (as opposed to a dependency on control as in the case
of call strings).
Example 2.41 Assume that we want to perform a Detection of Signs

Analysis (Example 2.36) of the Fibonacci program of Example 2.33 and that
the extrema! value Lsign is the singleton [x 1--+ +, y ~--+ -, z 1--+ -]. Then the
contexts of primary interest will be sets consisting of some of the following
abstract states
[x ~--+ +, y 1--+ O, z 1--+ -], [x ~--+ +, y ~--+O, z ~--+O], [x ~--+ +, y 1--+ O, z ~--+ +],
[x ~--+ +, y 1--+ +, z 1--+ [x ~--+ +, y ~--+ +, z ~--+O], (x 1--+ +, y 1--+ +, z ~--+ +]
.
-],
corresponding to the states in which the call-statements may be encoun-

~.
For a procedure call (fc,fn,fx,fr) E IF, i.e. [ca:.:_p(a,z)]~~ in the case of

forward analysis, we define the transfer function Jfc for procedure call by:
Î[ (Z) = u{{ 8'} X cf{ (d) 1 ( 8, d) E Z 1\
8' = {d" 1 (8, d") E Z}}
where </{ : D ---t P(D). The idea is as follows: a pair (8, d) E Z describes a
context and an abstract state for the current call. We now have to modify
the context to take the call into account, i.e. we have to determine the set of
possible abstract states in which the call could happen in the current context
and this is 8' = { d" 1 (8, d") E Z}. Given this context we proceed as in
the call string formulations presented above and mark the data flow property
fi- i
with this context.
Next we shall consider the transfer function c, r
for procedure return
i[;r (Z,Z') = U{{8} X </{,dd,d') 1 (8,d) E Z 1\ (8 1 ,d1 ) E Z 1 /\

8' = { d" 1 (8, d") E Z}}
where </J~ i : D x D ---t P(D). Here (8, d) E Z describes the situation

before th~, ;an and (8', ~ E Z' describes the situation at the procedure exit.
From the definition of Jfc we know that the context matching (8, d) will be
8' = { d" 1 ( 8, d") E Z} so we impose that condition. We can now combine
information from before the call with that at the procedure exit much as in
the call string approach; in particular, we can reset the context to be that of
the call point.
There is one important snag with the definitions of the transfer functions
jf and J[; : they are in general not monotone! One way to overcome
this proble~ ris to consider more general techniques for solving systems of
equations where the transfer functions satisfy a weaker condition than mono-
tonicity; we provide references to this approach in the Concluding Remarks.
Another way to overcome the problem is to use more approximate defini-
tions that are indeed monotone; one possibility is to replace the condition
8' = {d" 1 (8,d") E Z} by 8' ~ {d" 1 (8,d") E Z}. An even more ap-
proximate, but computationally more tractable, solution is to use smaller
assumption sets as detailed below.
Small assumption sets. As a simpler version of using assumption

sets one may take
and then use î = {(t, t)} as the extrema! value. So rather than basing the
embellished Monotone Framework on P(D) x D as above we now base it on
D x D. Of course, this is much less precise but, on the positive side, the size
of the data flow properties has been reduced dramatically.
For a procedure call (fc, fn,!.:_, fr) E IF, i.e. [call p(a, z)J~: for forward anal-
yses, the transfer function JL is now defined by
i[ (Z) = U{{d} x q{(d) 1(8,d) E Z}

where, as before, c/{ : D - t P(D). Here the individual pieces of information
concerning the abstract state of the call have their own local contexts; we
have no way of grouping the abstract states corresponding to 8 as we did in
---
the approach with large assumption sets.
The corresponding definition of the transfer function fi l for procedure
return then is c, r
i[;r (Z,Z') = U{{J} X c/{,R)d,d') 1 (J,d) E Z 1\ (d,d') E Z'}
where again c/JE l : D x D - t P(D). Examples of how to use assumption

sets will be co~'idered in the exercises.
2.5.6 Flow-Sensitivity versus Flow-Insensitivity

All of the data flow analyses we have considered so far have been fiow-
sensitive: this just means that in general we would expect the analysis of
a program 8 1; 8 2 to differ from the analysis of the program 82; 81 where the
statements come in a different order.
Sometimes one considers fiow-insensitive analyses where the order of state-
ments is of no importance for the analysis being performed. This may sound
weird at first, but suppose that the analysis being performed is like the ones
considered in Section 2.1 except that for simplicity all kill components are
empty sets. Given these assumptions one might expect that the programs
8 1 ; 8 2 and 8 2 ; 8 1 give rise to the same analysis. Clearly a flow-insensitive
analysis may be much less precise than its flow-sensitive analogue but also it
is likely to be much cheaper; since interprocedural data flow analyses tend
to be very costly, it is therefore useful to have a repertoire of techniques for
reducing the cost.
Sets of assigned variables. We shall now present an example of a

flow-insensitive analysis. Consider a program P* of the form begin D* 8*
end. For each procedure
proc p(val x, res y) isln 8 end""
inD*, the aim is to determine the set IAV(p) of global variables that might
be assigned directly or indirectly when p is called.
To compute these sets we need two auxiliary notions. The set AV(8) of
directly assigned variables gives for each statement 8 the set of variables
that could be assigned in 8 - but ignoring the effect of procedure callso It is

defined inductively upon the structure of 8:
AV([skip] 1) 0
AV([x := a]l) {x}
AV(81;S2) AV(81) U AV(82)
AV(if [b]~' then 81 else 82) AV(81) u AV(82)
AV(while [W do 8) AV(S)
AV([call p(a, z)]~~) {z}
Similarly we shall need the set CP( 8) of immediately called procedures that
gives for each statement 8 the set of procedure names that could be directly
called in 8- but ignoring the effect of procedure callso It is defined inductively
upon the structure of 8:
CP([skip]~') 0
CP([x := a]~') 0
CP(81;82) CP(81) u CP(82)
CP(if [b]~' then 81 else 82) CP(81) u CP(82)
CP(while [b]' do 8) CP(8)
CP([call p(a, z)]~~) {p}
Both the sets AV( 8) and CP( 8) are well-defined by induction on the structure
of S; also it should be clear that they are context-insensitive in the sense that
any rearrangement of the statements inside 8 would have given the same
resulto The information in CP(o oo) can be presented graphically: let the
graph have a node for each procedure name as well as a node called main*
for the program itself, and let the graph have an edge from p (respectively
main*) to p' whenever the procedure body 8 of p has p' E CP(8) (respectively
p' E CP( S*)) o This graph is usually called the procedure call grapho
We can now formulate a system of data fl.ow equations that specifies how to
obtain the desired sets IAV(p):
IAV(p) = (AV(8) \ {X}) u U{IAV(p') 1 p' E CP(8)}

where proc p( val x, res y) is'n 8 end'"' is in D*
By analogy with the considerations in Section 201 we want the least solution
of this system of equationso
Figure 2.11: Procedure call graph for example program.
Example 2.42 Let us now consider the following version of the Fibonacci
program (omitting labels):
begin proc fib(val z) is if z<3 then call add(1)

else (call fib(z-1); call fib(z-2))
end;
proc add(val u) is (y:=y+u; u:=O)
end;
y:=O; call fib(x)
end
We then get the following equations
IAV(fib) (0 \ {z}) U IAV(fib) U IAV(add)

IAV(add) {y,u}\{u}
The associated procedure call graph is shown in Figure 2.11. The least solu-
tion to the equation system is
IAV(fib) = IAV(add) = {y}

showing that only the variable y will be assigned by the procedure calls.
(Had we instead taken the greatest solution to the equations we would have
IAV(fib) = IAV(add) = Var* for any set Var* of variables that contains
those used in the program and this would be completely unusable.) •
Note that the formulation of the example analysis did not associate infor-
mation with entries and exits of blocks but rather with the blocks (or more
generally the statements) themselves. This is a rather natural space saving
approach for a context-insensitive analysis. It also relates to the discussion
of Type and Effect Systems in Section 1.6: the "annotated base types" m
Table 1.2 versus the "annotated type constructors" in Table 1.3.
2.6 Shape Analysis

We shall now study an extension of the WHILE-language with heap allocated
data structures and an intraprocedural 8hape Analysis that gives a finite
characterisation of the shapes of these data structures. So while the aim of
the previous sections has been to present the basic techniques of Data Flow
Analysis, the aim of this section is to show how the techniques can be used
to specify a rather complex analysis.
Shape analysis information is not only useful for classical compiler optimisa-
tions but also for software development tools: the Shape Analysis will allow
us to statically detect errors like dereferencing a nil-pointer - this is guar-
anteed to give rise to a dynamic error and a warning can be issued. Perhaps
more surprisingly, the analysis allows us to validate certain properties of the
shape of the data structures manipulated by the program; we can for exam-
ple validate that a program for in-situ list reversal does indeed transform a
non-cyclic list into a non-cyclic list.
Syntax of the pointer language. We shall study an extension of

WHILE that allows us to create cells in the heap; the cells are structured and
may contain values as well as pointers to other cells. The data stored in a
cell is accessed via selectors so we assume that a finite and non-empty set
Sel of selector names are given:
sel E Sel selector names
As an example Sel may include the Lisp-like selectors car and cdr for seled-
ing the first and second components of pairs. The cells of the heap can be
addressed by expressions like x.cdr: this will first determine the cell pointed
to by the variable x and then return the value of the cdr field. For the sake of
simplicity we shall only allow one level of selectors although the development
generalises to severallevels. Formally the pointer expressions
p E PExp
are given by:
p ::= x 1 x.sel
The syntax of the WHILE-language is now extended to have:
a P 1 n 1 a1 OPa a2 1 nil
b .. - true 1 false 1 not b 1 b1 opb b2 1 a1 opr a2 1 opP p
8 ··- [p:=a]l 1 [skip]l 1 81; 82 1
if [b]l then 81 else 82 1 while [b]l do 8 1
[malloc p]l
Arithmetic expressions are extended to use pointer expressions rather than
just variables, and an arithmetic expression can also be the constant nil.
2.6 Shape Analysis 105
The binary operations opa are as before, that is, they are the standard arith-
metic operations and in particular they do not allow pointer arithmetic. The
boolean expressions are extended such that the relational operators opr now
allow testing for the equality of pointers and also we shall allow unary opera-
tions opP on pointers (as for example is-nil and has-sel for each sel E Sel).
Note that arithmetic as well as boolean expressions can only access cells in
the heap, they cannot create new cells nor update existing cells.
The assignment statement takes the general form p: =a where p is a pointer
expression. In the case where p is just a variable we have an extension of the
ordinary assignment of the WHILE language and in the case where p contains
a selector we have a destructive update of the heap. The statements of the
extended language also contain a statement malloc p for creating a new cell
pointed to by p.
Example 2.43 The following program reverses the list pointed to by x

and leaves the result in y:
[y:=nil] 1 ;
while [not is-nil(x}F do
([z:=y]3; [y:=x] 4 ; [x:=x.cdr] 5 ; [y.cdr:=z] 6 );
[z:=nilf
Figure 2.12 illustrates the effect of the program when x points to a five
element list and y and z are initially undefined. Row O shows the heap just
before entering the while-loop: x points to the list and y is nil (denoted
by <>); to avoid cluttering the figure we do not draw the car-pointers. After
having executed the statements of the body of the loop the situation is as in
row 1: x now points to the tail of the list, y points to the head of the list and
z is nil. In general the n'th row illustrates the situation just before entering
the loop the n + 1'th time so in row 5 we see that x points to nil and the
execution of the loop terminates and y points to the reversed list. The final
statement z: =nil simply removes the pointer from z to ~4 and sets it to the
nil-value. •

To model the scenario described above we shall introduce an infinite set Loc
of locations (or addresses) for the heap cells:
~ E Loc locations
The value of a variable will now either be an integer (as before), a location
(i.e. a pointer) or the special constant <> reflecting that it is the nil value.
Thus the states are given by
a E State = Var* ---+ (Z + Loc + {<>})
0: Y --o
z --o
2:
3:
4:
x--o
5:
Figure 2.12: Reversal of a list of five elements.
where as usual Var* is the (finite) set of variables occurring in the program
of interest. As mentioned above the cells of the heap have multiple fields and
they are accessed using the selectors. Each field can either be an integer, a
pointer to another cell or it can be nil. We formalise this by taking
H E Heap =(Loc x Sel) -+fin (Z +Loc+ {o})

where the use of partial functions with finite domain reflects that not all
selector fields need to be defined; as we shall see later, a newly created cell
with location ~ will have all its fields to be uninitialised and hence the corre-
sponding heap H will have H(~, sel) tobe undefined for all sel E Sel.
Pointer expressions. Given a state and a heap we need to determine

the value of a pointer expression p as an element of Z + Loc + {o}. For this
we introduce the function
p : PExp*- (State x Heap) -fin (Z +{o}+ Loc)
where PExp* denotes pointer expressions with variables in Var*. It is de-

fined by:
p[x](a, H) a(x)
H(a(x), sel)
{ if a(x) E Loc and 1i is defined on (a(x), sel)
p[x.sel](a, H)
undef
if a(x) fţ Loc or H is undefined on (a(x), sel)
The first clause takes care of the situation where p is a simple variable and
using the state we determine its value - note that this may be an integer,
a location or the special Iiil-value o. The second clause takes care of the
case where the pointer expression has the form x.sel. Here we first have to
determine the value of x; it only makes sense to inspect the sel-field in the
case x evaluates to a location that has a sel-field and hence the clause is split
into two cases. In the case where x evaluates to a location we simply inspect
the heap H to determine the value of the sel-field - again we may note that
this can be an integer, a location or the special value o.
Example 2.44 In Figure 2.12 the oval nodes model the cells of the heap
H and they are labelled with their location (or address). The unlabelled edges
denote the state a: an edge from a variable x to some node labelled ~ means
that a(x) = ~; an edge from x to the symbol o means that a(x) = o. The
labelled edges model the heap H: an edge labelled sel from a node labelled
~ to a node labelled e means that there is a sel pointer between the two
cells, that is H(~, sel) =~';an edge labelled sel from a node labelled ~ to the
symbol o means that the pointer is a nil-pointer, that is H(~, sel) =o.
Consider the pointer expression x.cdr and assume that a and H are as
in row O of Figure 2.12, that is a(x) = 6 and H(6, cdr) = 6. Then
p[x.cdr](a, H) = 6. •
Arithmetic and boolean expressions. It is now straightforward

to extend the semantics of arithmetic and boolean expressions to handle
pointer expressions and the nil-constant. Obviously the functionality of the
semantic functions A and B has tobe changed to take the heap into account:
A : AExp ---+ (State x Heap) ---+fin (Z + Loc + {o})

B : BExp---+ (State x Heap) ---+fin T
The clauses for arithmetic expressions are
A[p](a, H) g:J[p](a, H)
A[n](a, H) = N[n]
A[a1 opa a2](a, H) A[ai](a, H) opa A[a2](a, H)
A[nil](a, H) o
where we use gJ to determine the value of pointer expressions and we explicitly

write that the meaning of nil is o. Also the meaning opa of the binary oper-
ation opa has to be suitably modified to be undefined unless both arguments
are integers in which case the results are as for the WHILE-language.
The definition of the semantics of boolean expressions is similar so we only
give two of the clauses:
B[a1 opr a2](a, H) A[ai](a, H) opr A[a2](a, H)

B[opP p](a, H) opP (g:J[p] (a, 1i))
Analogously to above, the meaning opr of the binary relation operator opr
has to be suitably modified to give undefined in case the arguments are not
both integers or both pointers (in which case the equality operation tests for
the equality of the pointers). The meaning of the unary operation opP is
defined by opP; as an example:
. "l( ) =
18-lll V
{ tt if V = O
ff otherw1se
.
Statements. Finally, the semantics of statements is extended to cope

with the heap component. The configurations will now contain a state as
well as a heap so we have
([x:=a]f, a, H)---+ (a[x f--+ A[a](a, H)], rt}

if A[a](a, rt) is defined
refl.ecting that for the assignment x: =a the state is updated as usual and the
heap is left unchanged. In the case where we assign to a pointer expression
containing a selector field we shallleave the state unchanged and update the
heap as follows:
([x.sel :=a]f, a, rt}---+ (a, rt[(a(x), sel) f--+ A[a](a, rt)]}

if a(x) E Loc and A[a](a, rt) is defined
Here the side condition ensures that the left hand side of the assignment does
indeed evaluate to a location.
The construct malloc p is responsible for creating a new cell. We have two
clauses depending on the form of p:
([malloc x]", cr, 'H)--+ (cr[x ~---+ ~], 'H)
where ~ does not occur in cr or 'H
m
([malloc (x.sel)J",cr,'H)--+ (cr,'H[(cr(x),sel) 1--+
where ~ does not occur in cr or 'Hand cr(x) E Loc
Note that in both cases we introduce a fresh location ~but we do not specify
any values for 'H(~, sel) -as discussed before we have settled for a semantics
where the fields of~ are undefined; obviously other choices are possible. Also
note that in the last clause the side condition ensures that we already have a
location corresponding to x and hence can create an edge to the new location.
Remark. The semantics only allows a limited reuse of garbage locations.
For a statement like [malloc xjl; [x:=nilj2; [malloc yj3 we will assign some
location to x at the statement with labei 1 and since it neither occurs in
the state nor the heap after the assignment labelled 2 we are free to reuse
it in the statement labelled 3 (but we do not have to). For a statement like
[malloc x]\ [x.cdr:=nilj2; [x:=nilj3; [malloc y] 4 we would not be able to
reuse the location allocated at 1 although it will be unreachable (and hence
garbage) after the statement labelled 3. •
2.6.2 Shape Graphs

It should be evident that there are programs for which the heap can grow ar-
bitrarily large. Therefore the aim of the analysis will be to come up with finite
representations of it. To do so we shall introduce a method for combining the
locations of the semantics into a finite number of abstract locations. We then
introduce an abstract state S mapping variables to abstract locations (rather
than locations) and an abstract heap H specifying the links between the ab-
stract locations (rather than the locations). More precisely, the analysis will
operate on shape graphs (S, H, is) consisting of:
• an abstract state, S,
• an abstract heap, H, and
• sharing information, is, for the abstract locations.
The last component allows us to recover some of the imprecision introduced

by combining many locations into one abstract location. We shall now de-
scribe how a given state cr and heap 'H give rise to a shape graph (5, H, is); in
doing so we shall specify the functionality of S, H and is in detail as well as
formulate a total of five invariants.
Abstract locations. The abstract locations have the form nx where

X is a subset of the variables of Var*:
ALoc= {nx 1 X~ Var*} abstract locations
Since Var* is finite it is clear that ALoc is finite and a given shape graph
will contain a subset of the abstract locations of ALoc.
The idea is that if x E X then the abstract location nx will represent the lo-
cation t1(x). The abstract location n0 is called the abstract summary location
and will represent ali the locations that cannot be reached directly from the
state without consulting the heap. Clearly nx and n0 will represent disjoint
sets of locations when X =/= 0.
In general, we shall enforce the invariant that two distinct abstract locations
nx and ny always represent disjoint sets of locations. As a consequence, for
any two abstract locations nx and ny it is either the case that X = Y or
that X n Y = 0. To prove this assume by way of contradiction that X=/= Y
and that z E X n Y. From z E X we get that t1(z) is represented by nx and
similarly z E Y gives that t1(z) is represented by ny. But then t1(z) must be
distinct from t1(z) and we have the desired contradiction.
The invariant can be formulated as follows:
Invariant 1. If two abstract locations nx and ny occur in the same

shape graph then either X= Y or X n Y = 0.
Example 2.45 Consider the state and heap in row 2 of Figure 2.12. The
variables x, y and z point to different locations (6, 6, and 6, respectively)
so in the shape graph they will be represented by different abstract locations
named n{x}' n{y} and n{z}· The two locations ~4 and 6 cannot be reached
directly from the state so they will be represented by the abstract summary
location n0. •
Abstract states. One of the components of a shape graph is the ab-

stract state, S, that maps variables to abstract locations. To maintain the
naming convention for abstract locations we shall ensure that:
Invariant 2. If x is mapped to nx by the abstract state then x E X.
From Invariant 1 it follows that there will be at most one abstract location
in the shape graph containing a given variable.
We shall only be interested in the shape of the heap so we shall not distinguish
between integer values, nil-pointers and uninitialised fields; hence we can
view the abstract state as an element of
SE AState = P(Var* x ALoc)

where we have chosen to use powersets so as to simplify the notation in later

parts of the development. We shall write ALoc(S) = {nx 1 3x: (x, nx) E S}
for the set of abstract locations occurring in S. (Note that AState is too
large in the sense that it contains elements that do not satisfy the invariants.)
Abstract heaps. Another component of the shape graph is the abstmct

heap, H, that specifies the links between the abstract locations (just as the
heap specifies the links between the locations in the semantics). The links
will be specified by triples (nv, sel, nw) and formally we take the abstract
heap as an element of
H E AHeap = P(ALoc x Sel x ALoc)
where we again do not distinguish between integers, nil-pointers and unini-

tialised fields. We shall write ALoc(H) = { nv, nw 1 3sel : (nv, sel, nw) E H}
for the set of abstract locations occurring in H.
The intention is that if 1t(6, sel) = 6 and 6 and 6 are represented by nv
and nw, respectively, then (nv,sel,nw) E H.
In the heap 1t there will be at most one location 6 such that 1t(6, sel) =
6. The abstract heap only partly shares this property because the abstract
location n0 can represent severa} locations pointing to different locations.
However, the abstract heap must satisfy:
Invariant 3. Whenever (nv,sel,nw) and (nv,sel,nw') are in the

abstract heap then either V = 0 or W = W'.
Thus the target of a selector field will be uniquely determined by the source
unless the source is the abstract summary location n0.
Example 2.46 Continuing Example 2.45 we can now see that the ab-
stract state S2 corresponding to the state of row 2 of Figure 2.12 will be
The abstract heap H2 corresponding to row 2 has
H2 = {(n{x}• cdr, n0), (n0, cdr, n0), (n{y}• cdr, n{z})}

The first triple reflects that the heap maps 6 and cdr to ~4, 6 is represented
by n{x} and ~4 is represented by n0. The second triple reflects that the heap
maps ~4 and cdr to ~5 and both ~4 and ~5 are represented by n0. The final
triple reflects that the heap maps 6 and cdr to 6, 6 is represented by n{y}
and 6 is represented by n{z}· Note that there is no triple (n{z},cdr,n0)
because the heap maps 6 and cdr to <> rather than a location.
The resulting abstract state and abstract heap is illustrated in Figure 2.13
together with similar information for the other states and heaps of Figure
cdr
X~
1:
2: 3: y
X ---r:::EI:I
4: y 5: y
z z
Figure 2.13: Shape graphs corresponding to Figure 2.12.
2.12. The square nodes model abstract locations; the unlabelled edges from
variables to square nodes model the abstract state and the labelled edges
between square nodes model the abstract heap. If the abstract state does
not associate an abstract location with some variable then that variable does
not occur in the picture.
Note that even if the semantics uses the same locations throughout the
computation it need not be the case that the locations are associated with
the same abstract locations at all points in the analysis. Consider Figures
2.12 and 2.13: the abstract location n0 will in turn represent the locations
{6,6,~4,~5}, {6,~4,6}, {~4,~5}, {6,~5}, {6,6} and {6,6,6}. •
Sharing information. We are now ready to introduce the third and

final component of the shape graphs. Consider the top row of Figure 2.14.
The abstract state and abstract heap to the right represent the state and the
heap to the left but they also represent the state and the heap shown in the
second row. We shall now show how to distinguish between these two cases.
The idea is to specify a subset, is, of the abstract locations that represent
locations that are shared due to pointers in the heap: an abstract location
nx will be included in is if it does represent a location that is the target of
more than one pointer in the heap. In the top row of Figure 2.14, the abstract
location n{y} represents the location ~5 and it is not shared (by two or more
heap pointers) so n{y} ~ is; the fat box indicates that the abstract location is
unshared. On the other hand, in the second row ~5 is shared (both 6 and ~4
point to it) so n{y} E is; the double box indicates that the abstract location
might be shared.
cdr
x~~cdr
X
y
y
cdr
X~~
X
0 y
y
0~
X
cdr
X~
y
y
Figure 2.14: Sharing information.
Obviously, the abstract heaps themselves also contain some implicit sharing
information: this is illustrated in the bottom row of Figure 2.14 where there
are two distinct edges with target n{y}. We shall ensure that this implicit
sharing information is consistent with the explicit sharing information (as
given by is) by imposing two invariants. The first ensures that information
in the sharing component is also refl.ected in the abstract heap:
Invariant 4. If nx E is then either
(a) (n0, sel, nx) is in the abstract heap for some sel, or
(b) there exists two distinct triples (nv,seh,nx) and (nw,seh,nx)
in the abstract heap (that is either seh =f. sel2 or V =f. W).
Case 4(a) takes care of the situation where there might be severallocations
represented by n0 that point to nx (as in the second and third rows of
Figure 2.14). Case 4(b) takes care of the case where two distinct pointers
(with different source or different selectors) point to nx (as in the bottom
row of Figure 2.14).
The second invariant ensures that sharing information present in the abstract
heap is also refl.ected in the sharing component:
Invariant 5. Whenever there are two distinct triples (nv,seh,nx)

and (nw, sel 2, nx) in the abstract heap and nx =f. n0 then nx E is.
This takes care of the case where nx represents a single location being the
target of two or more heap pointers (as in the bottom row of Figure 2.14).
Note that invariant 5 is the "inverse" of invariant 4(b) and that we have no
"inverse" of invariant 4(a) - the presence of a pointer from n0 to nx gives
no information about sharing properties of nx.
In the case of the abstract summary location the explicit sharing information
clearly gives extra information: if n0 E is then there might be a location
represented by n0 that is the target of two or more heap pointers, whereas
if n0 fţ is then all the locations represented by n0 will be the target of at
most one heap pointer. The explicit sharing information may also give extra
information for abstract locations nx where X i=- 0: from 4(a) alone we
cannot deduce that nx is shared- this is clearly illustrated for the node n{y}
by the top two rows of Figure 2.14.
The complete lattice of shape graphs. To summarise, a shape

graph is a triple consisting of an abstract state 5, an abstract heap H, and a
set is of abstract locations that are shared:
5 E AState P(Var* x ALoc)
H E AHeap = P(ALoc x Sel x ALoc)
is E IsShared = P(ALoc)
where ALoc= {nz 1 Z ~Var*}. A shape graph (5, H, is) is a compatible

shape graph if it fulfils the five invariants presented above:
1. Vnv, nw E ALoc(5) U ALoc(H) U is : (V = W) V (V nW = 0)
2. V(x, nx) E 5 : x E X
3. V(nv,sel,nw),(nv,sel,nw,)EH:(V=0) V (W=W')
4. Vnx E is : (3sel : (n0, sel, nx) E H) V
(3(nv,selt,nx),(nw,sel2,nx) E H:
seh i=- sel2 V V i=- W)
5. V(nv,selt,nx),(nw,sel2,nx) E H:
((seh i=- sel2 V Vi=- W) 1\ X i=- 0)::::} nx E is
The set of compatible shape graphs is denoted
SG = {(5, H, is) 1 (5, H, is) is compatible}

and the analysis, to be called Shape, will operate over sets of compatible
shape graphs, i.e. elements of P(SG). Since P(SG) is a powerset, it is
trivially a complete lattice with U being U and [;";; being ~. Furthermore,
P(SG) is finite because SG ~ AState x AHeap x IsShared and all of
AState, AHeap and IsShared are finite.
cdr
X~
Figure 2.15: The single shape graph in the extremal value L for the list
reversal program.
2.6.3 The Analysis

The analysis will be specified as an instance of a Monotone Framework with
the complete lattice of properties being P(SG). For each labei consistent
program s* with isolated entries we obtain a set of equations of the form
L if f = init(S*)
Shape0 (f) {
U{Shape.(f') 1 (f',f) E flow(S*)} otherwise
Shape.(f) = JJA(Shape 0 (f))
where L E P(SG) is the extremal value holding at entry to S* and JjA are
the transfer functions to be developed below.
The analysis is a forward analysis since it is defined in terms of the set
flow(S*), and it is a may analysis since we are using U as the combina-
tion operation. However, there are also aspects of a must analysis because
each individual shape graph must not contain any superfluous information.
This will be useful for achieving strong update and strong nullification; here
"strong" means that an update or nullification of a pointer expression allows
one to remove the existing binding before adding a new one. This in turn
leads to a very powerful analysis.
Example 2.47 Consider again the list reversal program of Example 2.43
and assume that x initially points to an unshared list with at least two el-
ements and that y and z are initially undefined; the singleton shape graph
corresponding to this state and heap is illustrated in Figure 2.15 and will be
the extrema} value L used throughout this development.
The Shape Analysis computes the sets Shape0 (f) and Shape.(f) of shape
graphs describing the state and heap before and after executing the elemen-
tary block labelled f. The equations for Shape. (f) are
Shape.(1) JrA (Shapea (1)) ffA(L)

Shape.(2) JiA(Shape 0 (2)) JiA(Shape.(1) U Shape.(6))
Shape.(3) JiA(Shape 0 (3)) fiA(Shape.(2))
Shape.(4) f~A (Shape0 ( 4)) Jr(shape.(3))
Shape.(5) f~A(Shape0 (5)) f~A (Shape. (4))
(5, H, is) (5', H', is')
Figure 2.16: The effect of [x:=nilf
Shape.(6) Jr(Shapeo (6)) Jr(shape.(5))

Shape.(7) = Jr(shape 0 (7)) !fA (Shape. (2))
where the transfer functions J[A will be specified below. In the examples
that follow we will provide further information about the equations but the
computation of Shape.(l), · · ·, Shape.(7) is left to Exercise 2.21. •
The transfer function J[A : P(SG) ---t P(SG) associated with a labei, l, has
the form:
j{A(SG) = U{ cf>EA((5, H, is)) 1 (5, H, is) E SG}
where cf>EA : SG ---t P(SG) specifies how a single shape graph (in Shape0 (l))
may be transformed into a set ofshape graphs (in Shape.(i)) by the elemen-
tary block labelled l. We shall now inspect the various forms of elementary
block and specify cf>~A in each case. We shall first consider the boolean ex-
pressions and the skip-statement, then the different forms of assignments
and finally the malloc-statement.
Transfer function for [W~ and [ski p jl. We are only interested in
the shape of the heap and the boolean tests do not modify the heap. Hence
we take
cf>EA((5, H, is)) = {(5, H, is)}
so that the transfer function J[A will be the identity function. Similarly for
the skip-statement.
Example 2.48 This case is illustrated by the test [not is-nil(x)j2 of

the list reversal program of Example 2.43: the transfer function JiA is the
identity function. Hence Shape.(2) = Shape.(l) U Shape.(6) as shown in
Example 2.47. •
Transfer function for [x: =a]R where a is of the form n, a1 opa a2 or

nil. The effect of this assignment will be to remove the binding to x, and
to rename all abstract locations so that they do not include x in their name.
The renaming of abstract locations is specified by the function
kx(nz) = nz\{x}
and we then take
cj.>~A((S, H, is)) = {killx((S, H, is))}
where killx((S, H, is)) = (S', H', is') is given by
S' {(z,kx(nz)) (z,nz) E S
1 1\ z =f. x}
H' {(kx(nv),sel,kx(nw)) (nv,sel,nw) E H}
1
is' {kx(nx) nx E is}

1
so that we obtain strong nullification. It is easy to check that if (S, H, is) is

compatible then so is (S', H', is').
Example 2.49 The statement [y:=niljl of the list reversal program of

Example 2.43 is of the form considered here. Since there is no occurrence of
y in the single shape graph in t of Figure 2.15, the shape graph Shape.(1) in
Example 2.47 is equal to t. •
An interesting case is when (x, n{ x}) E S since this will cause the two abstract
locations n{x} and n0 tobe merged. The sharing information is then updated
to capture that we can only be sure that n0 is unshared in the updated shape
graph if both n0 and n{x} were unshared in the original shape graph. This is
illustrated in Figure 2.16: the left hand picture shows the interesting parts of
the shape graph (S, H, is) and the right hand picture shows the corresponding
parts of (S', H', is'). We shall assume that the square boxes represent distinct
abstract locations so in particular V, {x}, W and 0 are all distinct sets.
The fat boxes represent unshared abstract locations as before, the thin boxes
represent abstract locations whose sharing information is not affected by the
transfer function, and unlabelled edges between abstract locations represent
pointers that are unaffected by the transfer function.
Example 2.50 The statement [z:=nilf of the list reversal program of

Example 2.43 illustrates this case: for each of the shape graphs of Shape.(2)
the abstract location n{z} is merged with n0 to produce one of the shape
graphs of Shape.(7). •
Remark. The analysis does not perform garbage collection: it might be

the case that there are no heap pointers to n{x} and then the corresponding
location in the heap will be unreachable after the assignment. Nonetheless
the analysis will merge the two abstract locations n{x} and n0 and insist on
a pointer from n0 to any abstract location that n{x} might point to. •
X
X
y y
(5, H, is) (5", H", is")
Figure 2.17: The effect of [x:=y]l when x-::j:.y.
Transfer function for [x:=y]l. If x = y then the transfer function

f'fA is just the identity.
Next suppose that x # y. The first effect of the assignment is to remove
the old bindings to x; for this we use the killx operation introduced above.
Then the new binding to x is recorded; this includes renaming the abstract
location that includes y in its variable set to also include x. The renaming
of the abstract locations is specified by the function:
Y(n ) = { nzu{x} if y E Z
9x z nz otherwise
We shall then take
<f>~A((5, H, is)) = {(5", H", is")}
where (5', H', is') = killx((5, H, is)) and
5" = {(z,g~(nz)) 1 (z, nz) E 5'}

U {(x,g~(ny)) 1 (y',ny) E 5' 1\y' = y}
H" {(g~(nv),sel,g~(nw)) 1 (nv,sel,nw) E H'}

is" = {g~(nz) 1 nz E is'}
so that we obtain strong update. Here the second clause in the formula for
5" adds the new binding to x. Again we note that if (5, H, is) is compatible
. (5" , H" , .1s") •
t hen so 1s
The clause is illustrated in Figure 2.17 where we assume that nodes represent
distinct abstract locations; it follows from the invariants that y E Y but y fţ. V
and y fţ. W. Note that nyu{x} inherits the sharing properties of ny although
both x and y will point to the same cell; the reason is that the sharing
information only records sharing in the heap- not sharing via the state.
Example 2.51 The statement [y: =x] 4 of the list reversal program of Ex-
ample 2.43 is of the form considered here: each of the shape graphs of
Shape.(3) in Example 2.47 is transformed into one of the shape graphs of
Shape.(4).
Also the statement [z: =yj3 is of the form considered here: each of the shape
graphs of Shape.(2) is transformed into one of those of Shape.(3). •
Transfer function for [x:=y.set]f. First assume that x = y; then

the assignment is semantically equivalent to the following sequence of assign-
ments
[t: =y.sel]l\ [x: =t]i 2 ; [t: =nil]i 3
where t is a fresh variable and €1, €2 and €3 are fresh labels. The transfer
function J'JA
can therefore be obtained as
!iSA = /SA
ia
0 /SA
i2
0 /SA
i1
where the transfer functions Jj2A and Jj3A follow the pattern described above.
ff
We shall therefore concentrate on the transfer function 1A, or equivalently,
JfA in the case where x -f=. y.
Example 2.52 The statement [x:=x.cdr] 5 of the list reversal program of
Example 2.43 is transformed into [t: =x.cdr] 51 ; [x: =tj5 2 ; [t: =ni1] 53 . We shall
return to the analysis of [t: =x.cdr] 51 later. •
So assume that x -f=. y and let (S, H, is) be a compatible shape graph before
the analysis of the statement. As in the previous case, the first step will be
to remove the old binding for x and again we use the auxiliary function killx:
(S', H', is') = killx ( (S, H, is))
The next step will be to rename the abstract location corresponding to y.sel
to include x in its name and to establish the binding of x to that abstract
location. We can now identify three possibilities:
1. There is no abstract location ny such that (y, ny) E S' or there is

an abstract location ny such that (y, ny) E S' but no nz such that
(ny,sel,nz) E H'; in this case the shape graph will represent a state
and a heap where y or y.sel is an integer, nil or undefined.
2. There is an abstract location ny such that (y, ny) E S' and there is
an abstract location nu -f=. n0 such that (ny, sel, nu) E H'; in this case
the shape graph will represent a state and a heap where the location
pointed to by y.sel will also be pointed to by some other variable (in U).
(S, H, is) (S", H", is")
Figure 2.18: The effect of [x: =y.set]l' in Case 2 when x f=-y.
3. There is an abstract location ny such that (y, ny) E S' and (ny, sel, n0)
E H'; in this case the shape graph will represent a state and a heap
where no other variable points to the location pointed to by y.sel.
Case 1. First consider the statement [x:=y.set]f (where x =/=- y) in the case
where there is no abstract location ny such that (y, ny) E S'. Then there is
no abstract location for y.sel and hence no abstract location to rename and
no binding to establish. Thus we take:
1>~A((S, H, is)) = {killx((S, H, is))}

Note that this situation captures the case where an attempt is made to deref-
erence a nil-pointer.
Alternatively, there is an abstract location ny such that (y, ny) E S' but there
is no abstract location n such that (ny,sel,n) E H'. From the invariants it
follows that ny is unique but stiH there is no abstract location to rename and
no binding to establish. So again we take:
1>zA((S, H, is)) = {killx((S, H, is))}

This situation captures the case where an attempt is made to dereference a
non-existing selector field of pointer.
Case 2. We consider the statement [x:=y.setjl (where x =/=- y) in the case
where there is an abstract location ny such that (y, ny) E S' and there is an
abstract location nu=/=- n0 such that (ny, sel, nu) E H'. Both ny and nu will
be uniquely determined because of the invariants (and they might be equal).
The abstract location nu will be renamed to include the variable x using the
function:
hu (n ) = { nuu{x} if Z = ~
x z nz otherw1se
We shall then take
4>7A((5, H, is)) = {(5", H", is")}
where (5', H', is') = killx((5, H, is)) and

5" {(z,h~(nz)) 1 (z,nz) E 5'}U{(x,h~(nu))}
H" {(h~(nv),sel',h~(nw)) 1 (nv,sel',nw) E H'}

is" {h~(nz) 1 nz E is'}
The inclusion of (x,h~(nu)) in 5" refiects the assignment. The definition of

is" ensures that sharing is preserved by the operation; in particular, nuu{x}
is shared in H" if and only if nu is shared in H'.
The effect of the assignment is illustrated in Figure 2.18 in the case where
nu E is. As before we assume that the abstract locations shown on the figure
are distinct so in particular Y, V and W are all distinct from U.
Case 3. We now consider the statement [x: =y.set]f (where x =j:. y) in the case
where there is an abstract location ny such that (y, ny) E 5' and furthermore
(ny, sel, n0) E H'. As before the invariants ensure that ny is uniquely deter-
mined. The location n0 describes the location for y.sel as well as a (possibly
empty) set of other locations. We now have to materialise a new abstract
location n{x} from n0; then n{x} will describe the location for y.sel and n0
will continue to represent the remaining locations. Having introduced a new
abstract location we will have to modify the abstract heap accordingly.
This is a potentially difficult operation, so let us consider the following se-
quence of assignments:
[x:=nn]···; [x:=y.set]f; [x:=nil]···
t
(5, H, is) 1 (S", J,,, is") 1
(5', H', is') (5"', H"', is111 )
Clearly [x:=nil]···; [x: =y.set]f is equivalent to [x:=y.set]f both in terms ofthe

analysis and the semantics. Indeed, (5', H', is') = killx((5, H, is)) represents
the effect of removing the binding to x. We are trying to determine candidate
shape graphs (5", H", is") holding after the assignment [x:=y.set]l (where
x =j:. y) but let us first study our expectations of (5"', H111 , is111 ). It is immediate
that (5 111 , H111 , is"') = killx((5", H", is")). Furthermore, the states and heaps
possible at the point described by (5', H', is') should be the same as those
possible at the point described by (5 111 , H"', is"'). This suggests demanding
that
(5 111 , H"', is111 ) = (5', H', is')
which means that killx ( (5", H", is")) = (5', H', is'). It is also immediate that
(x,n{x}) E 5" and that (ny,sel,n{x}) E H".
We shall then take
4>IA((5, H, is)) = {(5", H", is") 1 (5", H", is") is compatible 1\
killx ((5", H", is")) = (5', H', is') 1\
(x, n{x}) E 5" 1\ (ny, sel, n{x}) E H"}
where (5', H', is') = killx((5, H, is)).

It is hopefully clear that we have not missed any shape graphs (5", H", is")
that might be the result of the assignment. What might bea worry is that
we have included an excessive amount of irrelevant shape graphs. (Indeed
producing all compatible shape graphs would be trivially sound but also
utterly useless.) Although it is possible to do slightly better (see Exercise
2.23) we shall now argue that amount of imprecision in the above definition
is not excessive.
We first establish that
5" = 5' u {(x,n{x}H
showing that the abstract state is fully determined. Consider (z, n z) E 5". If
z = x it follows from the compatibility of (5", H", is") that nz = n{x}· If z =1-
x it follows from (x, n{x}) E 5" and the compatibility of (5", H", is") that x ţf.
Z and hence (z, nz) = (z, kx(nz )) (where kx is the auxiliary function used to
define the killx operation). This establishes that 5" ~ 5' U {(x, n{x}H· Next
consider (u, nu) E 5'. We know that u =1- x and x ţf. U from the definition
of 5' and from compatibility of (5', H', is'). There must exist (u, nf:r) E 5"
such that kx (nf:r) = nu but since x =1- u this gives nf:r = nu. It follows that
5" 2 5' U { (x, n{ x})} and we have proved the required equality.
We next establish that
is'\{n0} is"\{n0,n{x}}
n0 E is' iff n0 E is" V n{x} E is"
showing that
• abstract locations apart from n0 retain their sharing information,

• if n0 is shared then that sharing cannot go away but must give rise to
sharing of at least one of n0 or n{x}' and
• if n0 is not shared then no sharing can be introduced for n0 or n{x}·
Since both (5', H', is') and (5", H", is") are compatible shape graphs it follows
that if nu E is' then x ţf. U and if nu E is" then x ţf. U V {x} = U.
Hence is' = {kx(nu) 1 nu E is"} establishes is' \ {n0} = is" \ {n0,n{x}}
(5, H, is)
Figure 2.19: The effect of [x:=y.seljl in a special case (part 1).
because kx (nu) = nu /:- n0 for all nu E is" \ {n0, n{ x}}. Furthermore,

n0 E is" V n{ x} E is" gives n0 E is', and n0 tJ. is" 1\ n{ x} tJ. is" gives n0 tJ. is'.
Thus we have established the required relationship.
We now turn to the abstract heap. We shall classify the labelled edges
(nv, sel', nw) into four groups depending on whether or not the source or
target may be one of the nodes n0 or n{ x}:
(nv, sel', nw) is external iff {nv, nw} n {n0, n{x}} = 0

(nv,sel',nw) is internal iff {nv,nw} ~ {n0,n{x}}
(nv, sel', nw) is going-out iff nv E {n0, n{x}} 1\ nw tJ. {n0,n{x}}
(nv, sel', nw) is going-in iff nv tJ. {n0,n{x}} 1\ nw E {n0, n{x}}
We shall also say that two edges (nv, sel', nw) and (n~, sel", n~) are related
if and only if kx (nv) = kx (n~), sel' = sel" and kx (nw) = kx (n~). Clearly
an external edge is related only to itself.
Reasoning as above one can show that:
• H' and H" have the same external edges,
• each internal edge in H' is related to an internal edge in H" and vice
versa,
• each edge going-out in H' is related to an edge going-out in H" and vice
versa, and
• each edge going-in in H' is related to an edge going-in in H" and vice
versa.
(s "1, H"1, .l51") (s "2, H"2, .l52")
~
(s"3• H"3• .l53") (s "4• H"4• .l54")
X X
y y
(s "5, H"5, .15")

5 (S"6• H"6• 1'5")
6
Figure 2.20: The effect of [x:=y.seljl in a special case (part 2).
One consideration is that the going-in edge (ny, sel, n0) E H' should be
changed into the going-in edge (ny,sel,n}xJ) E H". We clearly demanded
that (ny, sel, n{ x}) E H" and because (S' , H", i511 ) is compatible it follows
that (ny,sel,n0) ~ H".
As a more concrete illustration consider the scenario in Figure 2.19. Here
neither n0 nor nw is shared and we assume that both nv and nw are distinct
from n0; we also assume that x # y and sel2 # sel3. The result of the
transfer function is shown in Figure 2.20. First note that the going-in edge
(ny, sel, n0) E H is changed to (ny, sel, n{x}) E H~' in all shape graphs. Next
note that the going-in edge labelled seh can only point to n0 because n{x} is
not shared (as n0 is not) and ny points to n{x}· The going-out edge labelled
sel 2 can start at both n0 and n{x} but it cannot do so simultaneously because
nw is not shared. The interna! edge labelled sel3 can only point to n0 because
n{x} is not shared and ny points to n{x}; but it can start at both n0 and n{x}
and can even do so simultaneously. This explains why there are six shape
graphs in q)~A((S, H, i5)), all of which are clearly needed.
Example 2.53 The statement [t: =x.cdr] 51 introduced in Example 2.52

is of the form considered here: the transfer function will transform each of
the shape graphs of Shape.(4) and subsequent transformations will produce
Shape.(5). •
Transfer function for [x.sel: =a]f' where a is of the form n, a 1 apa a 2

or nil. Again we consider a compatible shape graph (S, H, i5). First assume
that there is no nx such that (x, nx) E S; then x will not point to a cell
in the heap and the statement will have no effect on the shape of the heap
so the transfer function J'fA is just the identity. Next assume that there is
a (necessarily unique) nx such that (x, nx) E S but that there is no nu
such that (n x, sel, nu) E H; then the cell pointed to by sel does not point to
another cell so the statement will not change the shape of the heap and also
in this case the transfer function JiA
will be the identity.
The interesting case is when there are abstract locations nx and nu such that
(x,nx) E S and (nx,sel,nu) E H; these abstract locations will be unique
because of the invariants. The effect of the assignment will be to remove the
triple (nx,sel,nu) from H:
q)~A((S, H, i5)) = {killx.sei((S, H, i5))}
where killx.sez((S, H, i5)) = (S', H', i5') is given by:

S' s
H' {(nv,sel',nw) 1 (nv,sel',nw) E H 1\ •(X = V 1\ sel = sel')}
:5\{nu} if nu E i5 1\ #in ta( nu, H') :::; 1 1\
• 1
15 { ---,::Jsel' : (n(!J, sel', nu) E H'
15 otherwise
The sharing information is as before except that we may be able to do better

for the node nu - we have removed one of the pointers to it and in the case
where there is at most one pointer left and it does not have source n0 the
corresponding location will be unshared. This is yet another aspect of strong
update. Here we write #in ta( nu, H') for the number of pointers to nu in H'.
This clause is illustrated in Figure 2.21.
X X~
(5, H, is) (5', H', is')
Figure 2.21: The effect of [x.sel: =nil]R when #into(nu, H') ::;1.
Remark. Again we shall note that the analysis does not incorporate garbage
collection: it might be the case that there is only one pointer to the abstract
location nu and that after the assignment x.sel: =nil the corresponding lo-
cation will be unreachable. However, the abstract location may still be part
of the shape graph. •
Transfer function for [x.sel :=yY'. First assume that x = y. The

statement is then semantically equivalent to
[t: =y]e 1 ; [x.sel: =t]e 2 ; [t: =nil]e 3
where t is a fresh variable and C1, C2 and C3 are fresh labels. The transfer
function j'jA is then given by
! eSA = fSA
e3 0 fSA 0 fSA
e2 e1
The transfer functions f't
and j'j3A follow the pattern we have seen before
so we shall concentrate on the clause for Jit,
or equivalently, j'jA in the case
where x =/= y.
So assume that x =/= y and that (5, H, is) is a compatible shape graph. It may
be the case that there is no nx such that (x, nx) E 5 and in that case the
transfer function will be the identity since the statement cannot affect the
shape of the heap.
So assume that nx satisfies (x, nx) E 5. The case where there is no ny such
that (y, ny) E 5 corresponds to a situation where the value of y is an integer,
the nil-value or undefined and is therefore similar to the case [x.sel: =nil]e:
c/J~A((5, H, is)) = {killx.sez((5, H, is))}
The interesting case is when x =/= y, (x, nx) E S and (y, ny) E S. The first
step will be to remove the binding for x.sel and for this we can use the killx.sel
function. The second step will be to establish the new binding. So we take
cp~A((5, H, is)) = {(5", H", is")}
X X
(S, H, is) (S', H", is")
Figure 2.22: The effect of [x.sel: =y]t when #into(ny, H') < 1.
where (S', H', is') = killx.sez((S, H, is)) and
S" S' (= S)
H" H' U {(nx, sel,ny)}
is' U {ny} if #into(ny, H') ~ 1
is" {
is' otherwise
Note that the node ny might become shared when we add a new pointer to
it. The effect of the transfer function is illustrated in Figure 2.22.
Example 2.54 This transfer function is illustrated by the assignment

[y.cdr: =z] 6 of the list reversal program of Example 2.43: each of the shape
graphs of Shape.(5) in Example 2.47 are transformed into one of the shape
graphs of Shape.(6). •
Transfer function for [x.sel: =y.sel']e. This statement is equivalent

to the sequence of statement
[t: =y.sel']t 1 ; [x.sel: =t]t 2 ; [t: =nil]t3
for t being a fresh variable and ft, f2 and f3 being fresh labels. Thus the
transfer function JiA satisfies
! tSA = /SA
ta 0
/SA 0 fSA
t2 t1
The transfer functions 1A, /i fz:

and /'j3A all follow the patterns we have seen
before so this completes the specification of the transfer function.
Transfer function for [malloc p]e. We first consider the statement

[malloc x]t where we have to remove the binding for x and then introduce a
new (unshared) location pointed to by x. Thus we define
4>~A((S, H, is)) = {(S' U {(x, n{x})}, H', is')}

where (S', H', is') = killx(S, H, is).
The statement [malloc (x.sel}V is equivalent to the sequence
[malloc t]f 1 ; [x.sel: =t]f 2 ; [t: =nil]f 3
where t is a fresh variable and €1, €2 and €3 are fresh labels. The transfer
function f'fA is then
/z /z /J
The transfer functions 1A, 2A and 3A all follow the patterns we have seen
before so this completes the specification of the transfer function.
Concluding Remarks
Data Flow Analysis for imperative languages. As mentioned
in the beginning of this chapter, Data Flow Analysis has a long tradition.
Most compiler textbooks contain sections on optimisation which mainly dis-
cuss Data Flow Analyses and their implementation [5, 55, 181]. The emphasis
in these books is often on practica! implementations of data flow analyses. A
classic textbook which provides a more theoretical treatment of the subject
is by Hecht [69]; the book contains a detailed discussion of the four example
Data Flow Analyses in Section 2.1, and also presents a more traditional treat-
ment of Monotone Frameworks based on the use of semi-lattices as well as a
number of algorithms (see Chapter 6 for a more thorough treatment of algo-
rithms). Marlowe and Ryder [103] provide a survey of data flow frameworks.
Steffen [164] and Schmidt [151] express data flow analyses using modallogic
(rather than equations) thereby opening up the possibility of using model
checking techniques for program analysis.
The examples presented in Section 2.1 are fairly standard. Alternative treat-
ments of this material can be found in any of the books already cited. The
examples may ali be represented as Bit Vector Frameworks (see Exercise 2.9):
the lattice elements may be represented by a vector of bits and the lattice op-
erations efficiently implemented as boolean operations. The method used in
Section 2.2 to prove the correctness of the Live Variables Analysis is adapted
from [112] and is expressed by means of an operational semantics [140, 130].
The notion of faint variables, introduced in Exercise 2.4, was first introduced
by Giegerich, Moncke and Wilhelm [65].
The use of semi-lattices in Data Flow Analysis was first proposed in [96]. The
notion of Monotone Frameworks is due to Kam and Ullman [93]. These early
papers, and much of the later literature, use the dual notions (meets and
maximal fixed points) to our presentation. Kam and Ullman [93] prove that
the existence of a general algorithm to compute MOP solutions would imply
the decidability of the Modified Post Correspondence Problem [76]. Cousot
and Cousot [37] model abstract program properties by complete semi-lattices
in their paper on Abstract Interpretation (see Chapter 4).
We have associated transfer functions with elementary blocks. It would be

possible to associate transfer functions with flows instead as e.g. in [147].
These two approaches have equal power: to go from the first to the second,
the transfer functions may be moved from the blocks to their outgoing flows;
to go from the second to the first, we can introduce artificial blocks. In fact
artificial blocks can be avoided as shown in Exercise 2.11.
Most of the papers that we have cited so far concentrate on intraprocedural
analysis. An early, and influential, paper on interprocedural analysis is [155]
that studies two approaches to establishing context. One is based on call
strings and expresses aspects of the dynamic calling context; our presenta-
tion is inspired by [178]. The other is the "functional approach" that is based
on data and that shares some of the aims of assumption sets [99, 138, 145];
the technical formulation is different because [155] obtains the effect by cal-
culating the transfer functions for the call statement. Most of the subsequent
papers in the literature can be seen as variations and combinations over this
theme; a substantial effort in this direction may be found in [44]. As men-
tioned in Section 2.5.5, the use of large assumption sets may lead to equation
systems where the transfer functions are not monotone; we refer to [51, 52]
for a modern presentation of techniques that allow the solution of so-called
weakly monotonie systems of equations.
Pointer analysis. There is an extensive literature on the analysis of

alias problems for languages with pointers. Following [62] we can distinguish
between analyses of pointers to (1) statically allocated data (typically on
the stack) and (2) dynamically allocated data (typically in the heap). The
analysis of pointers to statically allocated data is the simplest: typically the
data will have compile-time names and the analysis result can be presented
as a set of points-to pairs of the form (p, x) meaning that the pointer p points
to the data x or as alias pairs of the form (*P, x) meaning that *P and x are
aliased. Analyses in this category include [47, 100, 145, 182, 162, 153].
The analysis of dynamically allocated data is more complicated since the
objects of interest are inherently anonymous. The simplest analyses [38,
61] study the connectivity of the heap: they attempt to split the heap into
disjoint parts and do not keep any information about the interna! structure
of the individual parts. These analyses have been found quite useful for many
applications.
The more complex analyses of dynamically allocated data give more precise
information about the shape of the heap. A number of approaches use graphs
to represent the heap. A main distinction between these approaches is how
they map a heap of potentially unbounded size to a graph of bounded size:
some bound the length of paths in the heap [84, 165], others merge heap cells
created at the same program point [85, 30], and yet others merge heap cells
that cannot be kept apart by the set of pointer variables pointing to them
[148, 149]. Another group of analyses obtain information about the shape
of the heap by more directly approximating the access paths. Here a main
distinction is the kind of properties of the access paths that are recorded:
some focus on simple connectivity properties [62], others use some limited
form of regular expressions [101], and yet others use monomial relations [45].
The analysis presented in Section 2.6 is based on the work of Sagiv, Reps
and Wilhelm [148, 149]. In contrast to [148, 149] it uses sets of compatible
shape graphs; [148, 149] merge sets of compatible shape graphs into a single
summary shape graph and then use various mechanisms for extracting parts
of the individual compatible shape graphs and in this way an exponential
factor in the cost of the analysis can be avoided. The sharing component of
the shape graphs is designed to detect list-like properties; it can be replaced
by other components detecting other shape properties [150].
Static Single Assignments. Some program analyses can be per-

formed more effi.ciently or more accurately when the program is transformed
into an intermediate form called static single assignment (SSA) form [42].
The benefit of SSA form is that the definition-use chains of the program are
explicit in the representation: each variable has at most one definition (mean-
ing that it is assigned at most once). As a consequence some optimisations
can be performed more effi.ciently using this representation [12, 180, 109, 110].
The transformation to SSA form amounts to renaming the variables and
introducing special assignments at the points where flow of control might
join. The assignments use so-called 4>-functions; each argument position of
the 4>- function identifies one of the program points where flow of control might
come from. The special statements have the form x : = cf>(x 1 , · · ·, Xn) and the
idea is that the value of x will equal the value of Xi whenever control comes
from the i'th predecessor. The algorithms for transforming to SSA form
often proceed in two stages: the first stage identifies the points where flow
of control might join and where the special assignments are to be inserted,
and the second stage renames the variables to ensure that each of them is
assigned at most once. To obtain a compact representation of the program
one wants to minimise the number of extra statements (and variables) and
there are techniques based on additional data flow information for achieving
this.
Data Flow Analysis for other language paradigms. The

analysis techniques that we have studied assume the existence of some rep-
resentation of the flow of control in the program. For the class of imperative
languages that we have studied, it is relatively easy to determine this control
flow information. For many languages, for example functional programming
languages, this is not the case. The next chapter presents techniques for de-
termining control flow inform~tion for such languages and shows how Data
Flow Analysis can be integrated with control flow analysis.
The techniques we have presented can be applied directly to other language

paradigms. Two examples are in object-oriented programming and a commu-
nicating processes language. Vitek, Horspool and Uhl [178] present an analy-
sis for object-oriented languages which determines classes of objects and their
lifetimes. Their analysis is an interprocedural analysis that uses a graph-
based representation of the memory as data flow values. Reif and Smolka
[142] apply Data Flow Analysis techniques to distributed communicating
processes to detect unreachable code and to determine the values of program
expressions. They apply their analysis to a language with asynchronous com-
munication. Their reachability analysis is based on an algorithm that builds
a spanning tree for each process flow graph and links matching transmits
and receives between processes. They construct a Monotone Framework for
determining value sets.
Intraprocedural control flow analysis. Many compilers trans-

form the source program into an intermediate form consisting of sequences
of fairly low-level instructions (like three address code) and then perform
the optimisations based on this representation. For this to work more in-
formation is needed about the flow of control within the individual program
segments; in our terminology we need the flow (or ilo~) relation in order
to apply the data flow analysis techniques. It is the task of intraprocedural
control flow analysis to provide this information.
More refined forms of intraprocedural control flow analysis include struc-
tural analysis [154, 110] that aims at discovering a wider variety of control
structures in the code- control structures like conditionals, while-loops and
repeat-loops that resemble those of the source language. The starting point
for structural analysis is the flow graph; it is examined to identify instances of
the various control structures, the instances are replaced by abstract nodes
and the connecting edges are collapsed; this process is repeated until the
flow graph has been collapsed into a single abstract node. The approach
described above is a refinement of classical techniques based on identifying
natural loops (or interval analysis [69, 5, 110]) intended to provide more
meaningful program structure.
We refer to the Concluding Remarks of Chapter 6 for a discussion of systems
implementing data flow analysers.
l[x := ···]···1
~
Î.J
ud-chain
~
\
()
r;
du-chain
1..1
Figure 2.23: du-and ud-chains.
Mini Projects
Mini Project 2.1 ud- and du-chains
The aim of this mini project is to developa more thorough understanding of

the concepts of ud- and du-chains introduced in Subsection 2.1.5.
1. The function ud is specified in terms of definition clear paths, whilst

UD re-uses functions introduced for the Reaching Definitions and Live
Variables Analyses. Prove that the two functions compute the same
information.
2. DU can be defined by analogy with UD. Starting from the definition of
du, develop an equational definition of DU and verify its correctness.
3. A Constant Propagation Analysis is presented in Subsection 2.3.3; an
alternative approach would be to use du- and ud-chains. Suppose there
is a block [x := n]e that assigns a constant n to a variable x. By
following the du-chain it is possible to find all blocks using the variable
x. It is only safe to replace a use of x by the constant n in a block f'
if all other definitions that reach i' also assign the same constant n to
x. This can be determined by using the ud-chain. This is illustrated
in Figure 2.23. Considering the program of Example 2.12, Constant
Folding (followed by Dead Code Elimination) can be used to produce
the following program:
(if [z=3] 3 then [z:=0] 4 else [z:=3] 5 ); [y:=3] 6 ; [x:=3+zf
Develop a formal description of this analysis. •

Mini Projects 133
[ass] ([x := a]e,a, tr)----+ (a[x 1--7 A[a]a], tr: (x,fl))

[skip] ([skip]e, a, tr) ----+ (a, tr)
(SI, a, tr)----+ (S~,a', tr')

[seqi]
(SI;S2,a, tr)----+ (S~;S2,a', tr')
(SI, a, tr) ----+ (a', tr')

[seq2]
(SI;S2,a,tr)----+ (S2,a',tr')
[ifil (if [bjf then SI el se S2, a, tr) ----+ (SI, a, tr) if B[b]a = true
[if2] (if [bjf then SI else S2, a, tr) ----+ (S2, a, tr) if B[b]a = false
[whi] (while [bjf do S, a, tr) ----+ ((S; while [bjf do S), a, tr)
if B[b]a = true
[wh2] (while [bjf do S, a, tr) ----+ (a, tr) if B[b]a = false
Table 2.10: The instrumented semantics of WHILE.
Mini Project 2.2 Correctness of Reaching Definitions
The aim of this mini project is to prove the correctness of Reaching Definitions
with respect to the notion of semantic reaching definitions introduced in
Section 1.5. To get a precise definition of the set of traces of interest we shall
begin by introducing a so-called instrumented semantics: an extension of a
more traditional semantics that keeps track of additional information that is
mainly of interest for the program analysis.
The instrumented semantics has transitions of the forms:
(S,a, tr)----+ (a', tr') and (S,a, tr)----+ (S',a', tr')
All configurations include a trace tr E Trace = (Var x Lab)* that records

the elementary block in which a variable is being assigned. The detailed
definition of the instrumented semantics is given in Table 2.10.
Given a program S* and an initial state a* E State it is natural to construct
the trace
where x 1 , · · · , Xn are the variables in Var* and to consider the finite derivat ion
sequence:
It should be intuitively obvious (and can be proved formally) that
tr' E TrVar: = {tr E Trace 1 Vx E Var*: :Jl' E Lab:: (x,l') occurs intr}
Intuitively (and as can be proved formally), there should bea similar deriva-
tion sequence (S*, CT*) --t* CT 1 in the Structural Operational Semantics. Simi-
lar remarks apply to infinite derivation sequences.
As in Section 2.2 we shall study the constraint system RD~ (S*) corresponding
to the equation system RD= (S*). Let reach be a collection of functions:
?
reachentry,reachexit: Lab* --t P(Var* x Lab~)
We say that reach solves RD~ (S), and write
reach f= RD~ (S)
if the functions satisfy the constraints; similarly for reach f= RD=(s).
1. Formulate and prove results corresponding to Lemmas 2.15, 2.16 and

2.18.
The correctness relation rv will relate traces tr E Trace to the information

obtained by the analysis. Let Y ~ P(Var* x Lab:) and define
tr"' Y iff Vx E DOM(tr) : (x, SRD(tr)(x)) E Y
meaning that Y contains at least the semantically reaching definitions ob-

tained from the trace tr by the function SRD introduced in Section 1.5.
(Note that DOM(tr) =Var* whenever tr E TrVar:.)
2. Formulate and prove results corresponding to Lemma 2.20, Theorem

2.21 and Corollary 2.22.
•
Mini Project 2.3 A Prototype lmplementation
In this mini project we shall implement one of the program analyses consid-
ered in Section 2.1. As implementation language we shall choose a functional
language such as Standard ML or Haskell. We can then define a suitable
Exercises 135
data type for WHILE programs as follows:

type var string
type label int
datatype aexp Var of var Const of int
1
Op of string * aexp * aexp

and bexp True 1 False
Not of bexp 1 Boolop of string * bexp * bexp
Relop of string * aexp * aexp
datatype stat Assign of var * aexp * label 1 Skip of label
Seq of stat * stat 1 lf of bexp * label * stat * stat
While of bexp * label * stat
Now proceed as follows:
1. lmplement the operations init, final, flow, flowR and blocks.

2. Generate the data flow equations for the Live Variables Analysis of
Subsection 2.1.4.
3. Solve the data flow equations; the function should be based on the
algorithm of Section 2.4.
For the more ambitious: generalise your program to accept an instance of a

Monotone Framework as input. •
Exercises
Exercise 2.1 Formulate data flow equations for the Reaching Definitions
Analysis of the program studied in Example 1.1 of Chapter 1 and in particular
define the appropriate gen and kill functions. •
Exercise 2.2 Consider the following program:

[x:=1]\ (while [y>0] 2 do [x:=x-1] 3 ); [x:=2] 4
Perform a Live Variables Analysis for this program using the equations of
Section 2.1.4. •
Exercise 2.3 A modification of the Available Expressions Analysis de-

tects when an expression is available in a particular variable: a non-trivial
expression a is available in x at a labei Cif it has been evaluated and assigned
to x on all paths leading to C and if the values of x and the variables in the
expression have not changed since then. Write down the data flow equations
and any auxiliary functions for this analysis. •
Exercise 2.4 Consider the following program:

[x:=1]\ [x:=x-1] 2 ; [x:=2] 3
Clearly x is dead at the exits from 2 and 3. But x is live at the exit of 1 even
though its only use is to calculate a new value for a variable that turns out to
be dead. We shall say that a variable is a faint variable if it is dead or if it is
only used to calculate new values for faint variables; otherwise it is strongly
live. In the example x is faint at the exits from 1, 2 and 3. Define a Data
Flow Analysis that detects strongly live variables. (Hint: For an assignment
[x := a]e the definition of fe(l) should be by cases on whether x is in l or
not.) •
Exercise 2.5 A basic block is often taken tobe a maximal group of state-
ments such that all transfers to the block are to the first statement in the
group and, once the block has been entered, all statements in the group are
executed sequentially. In this exercise we shall consider basic blocks of the
form
where n 2: O and B is x :=a, skip orb. Reformulate the analyses of Section

2.1 for this more general notion of basic block. •
Exercise 2.6 Consider the analyses Available Expressions and Reaching

Definitions. Which of the equations make sense for programs that do not
have isolated entries (and how can this be improved)? Similarly, which of
the equations for Very Busy Expressions and Live Variables make sense for
programs that do not have isolated exits (and how can this be improved)?
(Hint: See the beginning of Section 2.3.) •
Exercise 2. 7 Consider the correctness proof for the Live Variables Anal-
ysis in Section 2.2. Give a compositional definition of LV=(···) for a labei
consistent statement using
as one of the clauses and observe that a similar development is possible for
LV~(···). Give a formal definition of live f= C where C is a set of equalities
or inclusions as might have been produced by LV=(s) or LV~(S).
Prove that {live llive f= LV~(S)} is a Moare family in the sense of Appendix
A (with n being n and determine whether or not a similar result holds for
{live llive f= Lv=(s)}. •
Exercise 2.8 Show that Constant Propagation is a Monotone Framework

with the set :Fcp as defined in Section 2.3.3. •
Exercises 137
Exercise 2.9 A Bit Vector Framework is a special instance of a Monotone

Framework where
• L = (P(D), ~)for some finite set D and where ~ is either ~ or 2, and
• F = {!: P(D) -+ P(D) 1 3Yj, YJ ~ D : W ~ D :

f(Y) = (Y n Yj) UYj}
Show that the four classical analyses of Section 2.1 are Bit Vector Frame-
works. Show that all Bit Vector Frameworks are indeed Distributive Frame-
works. Devise a Distributive Framework that is not also a Bit Vector Frame-
work. •
Exercise 2.1 O Consider the Constant Propagation Analysis of Section
2.3.3 and the program
(if [· · ·] 1 then [x:=-1] 2 ; [y:=1] 3 else [x:=1] 4 ; [y:=-1] 5 ); [z:=x*y] 6
Show that MFP.(6) differs from MOP.(6). •

Exercise 2.11 In our formulation of Monotone Frameworks we associate
transfer functions with basic blocks. In a statement of the form
if [W then s1 else s2
this prevents us from using the result of the test to pass different information
to S1 and S2; as an example SUppose that X is known to be positive Or negative
and that b is the test x>O, then X is always positive at the entry to sl and
always negative at the entry to S2 . To remedy this deficiency consider writing
[b]l' as [b]l' 1 ,e2 where .e1 corresponds tob evaluating to true and .e2 corresponds
to b evaluating to false. Make the necessary changes to the development in
Sections 2.1 and 2.3. (Begin by considering forward analyses.) •
Exercise 2.12 Consider one of the analyses Available Expressions, Very

Busy Expressions and Live Variables Analysis and perform a complexity anal-
ysis in the manner of Example 2.30. •
Exercise 2.13 Let F be flow(S*) and E be {init(S*)} for a labei consis-

tent program S*. Show that
Prove a similar result when Fis flo~(S*) and E is final(S*). •

Exercise 2.14 In a Detection of Signs Analysis one models all negative

numbers by the symbol -, zero by the symbol O, and all positive numbers
by the symbol +. As an example, the set { -2, -1, 1} is modelled by the set
{ -, +}, that is an element of the powerset P( {-,O,+}).
Let S* be a program and Var* be the finite set of variables in S*. Take
L tobe Var*--+ P({-,0,+}) and define an instance (L,F,F,E,t,f.) of a
Monotone Framework for performing Detection of Signs Analysis.
Similarly, take L' to be P (Var* x {-, O, +}) and define an instance (L', F', F',
E', t 1, /!) of a Monotone Framework for Detection of Signs Analysis. Is there
any difference in the precision obtained by the two approaches? •
Exercise 2.15 In the previous exercise we defined a Detection of Signs

Analysis that could not record the interdependencies between signs of vari-
ables (e.g. that two variables x and y always will have the same sign); this is
sometimes called an independent attribute analysis. In this exercise we shall
consider a variant of the analysis that is able to record the interdependencies
between signs of variables; this is sometimes called a relational analysis. To do
so take L tobe P(Var*--+ {-,O,+}) and define an instance (L,F, F, E, t, f.)
of a Monotone Framework for performing Detection of Signs Analysis. Con-
struct an example showing that the result of this relational analysis may be
more informative than that of the independent attribute analysis. The dis-
tinction between independent attribute methods and relational methods is
further discussed in Chapter 4. •
Exercise 2.16 The interprocedural analysis using bounded call strings

uses contexts to record the last k call sites. Reformulate the analysis for a
notion of context that records the last k distinct call sites. Discuss whether
or not this analysis is useful for distinguishing between the call of a procedure
and subsequent recursive calls. •
Exercise 2.17 Consider the Fibonacci program of Example 2.33 and the
Detection of Signs Analysis of Exercise 2.15 and Example 2.36. Construct
the data flow equations corresponding to using large and small assumption
sets, respectively. •
Exercise 2.18 Choose one of the four classical analyses from Section 2.1
and formulate it as an interprocedural analysis based on call strings. (Hint:
Some may be easier than others.) •
Exercise 2.19 Extend the syntax of programs to have the form

begin D*; input x; S*; output y end
Exercises 139
so that it maps integers to integers rather than states to states. Consider the
Detection of Signs Analysis and define the transfer functions for the input
and output statements. •
Exercise 2.20 Consider extending the procedure language such that pro-
cedures can have multiple call-by-value, call-by-result and call-by-value-result
parameters as well as local variables and reconsider the Detection of Signs
Analysis. How should one define the transfer functions associated with pro-
cedure call, procedure entry, procedure exit, and procedure return? •
Exercise* 2.21 Compute the shape graphs Shape.(l), · · ·, Shape.(7) of

Example 2.47 using the information supplied in Examples 2.48, 2.54.
(Warning: there will be more than 50 shape graphs.) •
Exercise 2.22 In the Shape Analysis of Section 2.6 work out direct def-
initions of the transfer functions for elementary statements of the forms
[x: =x.seW, [x.sel: =x]R, [x.sel: =x.sel']R and [malloc (x.sel)jR. •
Exercise* 2.23 Consider Case 3 in the definition of the transfer function

for [x:=y.selJR (where x-:/=- y) in the Shape Analysis. Make a careful analy-
sis of interna!, going-in and going-out edges and determine whether or not
some of the shape graphs (S", H", is") in 1/>~A((S, H, is)) can be removed by
placing stronger demands on the edges in H" compared to those in H' (where
(S', H', is') = killx((S, H, is))). •
Exercise* 2.24 The Shape Analysis as presented in Section 2.6 does not
take garbage collection into account. Modify the Structural Operational Se-
mantics of the pointer language to perform garbage collection and subse-
quently modify the analysis to reflect this. •
Exercise* 2.25 The use of a single abstract summary location leads to a

certain amount of inaccuracy in the Shape Analysis. A more accurate anal-
ysis could associate allocation sites with the abstract locations. An abstract
location would then have the form ne,x where 1! is an allocation site (a label
of a malloc-statement) and X is a set of variables as before. Develop the
transfer functions for the new analysis. •
Chapter 3
Constraint Based Analysis
In this chapter we present the technique of Constraint Based Analysis us-

ing a simple functional language, FuN. We begin by presenting an abstract
specification of a Control Flow Analysis and then study its theoretical prop-
erties: it is correct with respect to a Structural Operational Semantics and it
can be used to analyse all programs. This specification of the analysis does
not immediately lend itself to an efficient algorithm for computing a solution
so we proceed by developing first a syntax directed specification and then
a constraint based formulation and finally we show how the constraints can
be solved. We conclude by illustrating how the precision of the analysis can
be improved by combining it with Data Flow Analysis and by incorporating
context information thereby linking up with the development of the previous
chapter.
3.1 Abstract 0-CFA Analysis

In Chapter 2 we saw how properties of data could be propagated through a
program. In developing the specification we relied on the ability to identify for
each program fragment all the possible successor (and predecessor) fragments
via the operator How (and Ro~) and the interprocedural flow inter-How*
(and inter-How;!). The usefulness of the resulting specification was due to
the number of successors and predecessors being small (usually just one or two
except for procedure exits). This is a typical feature of imperative programs
without procedures. but it usually fails for more general languages, whether
imperative languages with procedures as parameters, functional languages,
or object-oriented languages. In particular, the interprocedural techniques of
Section 2.5 provide a solution for the simpler cases where the program text
allows one to limit the number of successors, as is the case when a proce-
142 3 Constraint Based Analysis
dure call is performed by explicitly mentioning the name of the procedure.

However, these techniques are not powerful enough to handle the dynamic
dispatch problem where variables can denote procedures. In Section 1.4 we
illustrated this by the functional program
let f = fn x => x 1;
g = fn y => y+2;
h = fn z => z+3
in (f g) + (f h)
where the function application x 1 in the body of f will transfer control

to the body of the function x, and here it is not so obvious what program
fragment this actually is, since x is the formal parameter of f. The Control
Flow Analysis of the present chapter will provide a solution to the dynamic
dispatch problem by determining for each subexpression a hopefully small
number of functions that it may evaluate to; thereby it will determine where
the flow of control may be transferred to in the case where the subexpression
is the operator of a function application. In short, Control Flow Analysis
will determine the interprocedural ftow information (inter-flow* or IF) upon
which the development of Section 2.5 is based.
Syntax of the FUN language. For the main part of this chapter
we shall concentrate on a small functional language: the untyped lambda
calculus extended with explicit operators for recursion, conditiona} and local
definitions. The purpose of the Control Flow Analysis will be to compute
for each subexpression the set of functions that it could evaluate to, and to
express this it is important that we are able to labei all program fragments.
We shall be very explicit about this: a program fragment with a labei is
called an expression whereas a program fragment without a labei is called a
term. So we use the following syntactic categories:
e E Exp expressions (or labelled terms)
t E Term terms (or unlabelled expressions)
We assume that a countable set of variables is given and that constants
(including the truth values), binary operators (including the usual arithmetic,
boolean and relational operators) and labels are left unspecified:
J, xE Var variables
c E Const constants
op E Op binary operators
l E Lab labels
The abstract syntax of the language is now given by:
e .. - ti
t .. - c 1 x 1 fn x => eo 1 fun f x => eo 1 e1 e2
if eo then e1 else e2 llet x = e1 in e2 1 e1 op e2

Here fn x => e0 is a function definition (or function abstraction) whereas

fun f x => eo is a recursive variant of fn x => eo where ali free occurrences of
f in eo refer to fun f x => eo itself. The construct let x = e1 in e2 is a non-
recursive local definit ion that is semanticaliy equivalent to (fn x => e 2 ) (ei).
As usual we shali use parentheses to disambiguate the parsing whenever
needed. Also we shali assume throughout that in ali occurrences of fun f x =>
e0 , f and x are distinct variables.
We shali need the notion of free variables of expressions and terms so we
define the function
FV: (Term U Exp)--> P(Var)
in the foliowing standard way. The abstractions fn x => e0 and fun f x => e0
cont ain binding occurrences of variables so FV( fn x => e0 ) = FV( e0 ) \ { x} and
similarly FV(fun f x => eo) = FV(eo) \ {f,x}. Similarly, let x = e1 in e2
contains a binding occurrence of x so we have FV(let x = e 1 in e 2 ) =
FV( e 1) U (FV( e2) \ {x}) reflecting that free occurrences of x in e 1 are bound
outside the construct. The remaining clauses for FV are straightforward.
Example 3.1 The functional program (fn x => x) (fn y => y) consid-
ered in Section 1.4 is now written as:
Compared with the notation of Example 1.2 we have omitted the square
brackets. •
Example 3.2 Consider the foliowing expression, loop, of FuN:

(let g = (fun f x => (f 1 (fn y => y2)3)4)5
in (g6 (fn z => z7)8)9)lo
It defines a function g that is applied to the identity function fn z => z 7 .

The function g is defined recursively: f is its local name and x is the formal
parameter. Hence the function will ignore its actual parameter and call itself
recursively with the argument fn y => y 2 . This will happen again and again
so the program loops. •
3.1.1 The Analysis

Abstract domains. We shali now show how to specify 0-CFA analyses.
These may be regarded as the simplest possible form of Control Flow Analysis
in that no context information is taken into account. (As will become clear
in Section 3.6, this is what the number O is indicating.)
The result of a 0-CFA analysis is a pair (C, p) where:
• Cis the abstract· cache associating abstract values with each labelled
program point.
• p is the abstract environment associating abstract values with each
variable.
This is made precise by:
V E -----
Val = P(Term) abstract values
p E Env Var --t Val abstract environments
c E -----
Cache Lab --t
-----
Val abstract caches
v
Here an abstract value is an abstraction of a set of functions: it is a set of
terms of the form fn x => eo or fun f x =>ea. We will not be recording any
constants in the abstract values because the analysis we shall specify is a pure
Control Flow Analysis with no Data Flow Analysis component; in Section
3.5 we shall show how to extend it with Data Flow Analysis components.
Furthermore, we do not need to assume that all bound variables are distinct
and that all labels are distinct, but clearly, greater precision is achieved if
this is the case; this means that semantically equivalent programs can have
different analysis results and this is a common feature of all approaches to
program analysis. As we shall see an abstract environment is an abstraction
of a set of environments occurring in closures at run-time (see the semantics
in Subsection 3.2.1). In a similar way an abstract cache might be considered
as an abstraction of a set of execution profiles: as discussed below some texts
prefer to combine the abstract environment with the abstract cache.
Example 3.3 Consider the expression ((fn x => x1)2 (fn y => y3)4)5
of Example 3.1. The following table contains three guesses of a 0-CFA anal-
ysis:
(Ce, Pe) (c~, ~) (c~, fJ.{)

1 {fn y => y;j} {fn y => y-1} {fn x => x 1 , fn y => y;j}
2 {fn x => x 1 } {fn x => x 1 } {fn x => x 1 ,fn y => y3}
3 0 0 {fn x => xl, fn y => y3}
4 {fn y => y 3} {fn y => y 3} {fn x => x 1 , fn y => y3}
5 {fn y => y3} {fn y => y3} {fn x => x 1 , fn y => y3}
X {fn y => y 3} 0 {fn x => x 1 , fn y => y3}
y 0 0 {fn x => x 1 , fn y => y3}
Intuitively, the guess (Ce, Pe) of the first column is acceptable whereas the
guess (C~, P:,) of the second column is wrong: it would seem that fn x =>
x 1 is never called since ~(x) = 0 indicates that x will never be bound to
any closures. Also the guess (C~, fl:) of the third column would seem to be
acceptable although clearly more imprecise than (Ce, Pe)· •
Example 3.4 Let us consider the expression, loop, of Example 3.2 and
introduce the following abbreviations for abstract values:
f fun f x => (f 1 (fn y => y2)3)4

idy fn y => y2
~z fn z => z 7
One guess of a 0-CFA analysis for this program is (Cip, pjp) defined by:
C1p(1) {f} C1p(6) {f} Pip(f) {f}

clp(2) 0 clp(7) = 0 Pip(g) {f}
clp(3) {idy} clp(s) = {idz} Pip(x) {idy, idz}
clp(4) 0 clp(9) 0 Pip(y) 0
clp(5) {f} clp(lO) 0 Pip(z) 0
Intuitively, this is an acceptable guess. The choice of Plp(g) = {f} refl.ects that
g will evaluate to a closure constructed from that abstraction. The choice of
Pip(x) = {idy, idz} refl.ects that x will be bound to closures constructed from
both abstractions in the course of the evaluation. The choice of C1p(l0) = 0
refl.ects that the evaluation of the expression will never terminate. •
We have already said that Control Flow Analysis computes the interproce-
dural fl.ow information used in Section 2.5. It is also instructive to point
out the similarity between Control Flow Analysis and Use-Definition chains
( ud-chains) for imperative languages (see Subsection 2.1.5): in both cases we
attempt to trace how definition points reach points of use. In the case of
Control Flow Analysis the definition points are the points where the function
abstractions are created, and the use points are the points where functions
are applied; in the case of Use-Definition chains the definition points are the
points where variables are assigned a value, and the use points are the points
where values of variables are accessed.
Remark. Clearly an abstract cache C : Lab --+ Val and an abstract environ-
ment p: Var --+ Val can be combined into an entity of type (Var U Lab) --+
Val. Some texts dispense with the labels altogether, simply using an abstract
environment and no abstract cache, by ensuring that all subterms are prop-
erly "labelled" by variables. This type of expression frequently occurs in the
internals of compilers in the form of "continuation passing style", "A-normal
form" or "three address code". We have abstained from doing so in order to
illustrate that the techniques not only work for compiler intermediate forms
but also for general programming languages and calculi for computation; this
fl.exibility is useful when dealing with non-standard applications (as discussed
in the Concluding Remarks). •
[con] (C, P) f= d always

[var] (C, P) f= xt iff P(x) ~ C(l)
[Jn] (C,P) f= (fn x => eo)t iff {fn x => eo} ~ C(l)
[!un] (C,P) f= (fun f x => eo)e iff {fun f x => eo} ~ C(l)
[app] (C,P) F (til t~2)e
iff (C, P> F= til 1\ (C, p-) F= t~2 1\
(V(fn x => t~0 ) E C(lt) :
(c, ?) F= t~o 1\
C(l2) ~ p-(x) 1\ C(lo) ~ c(t)) 1\
(V(fun f x => t~0 ) E C(ll) :
(c, ?) F= t~o 1\
C(l2) ~ p-(x) 1\ C(lo) ~ c(t) 1\
{fun f X=> t~0 } ~ P(f))
[i~ (C, P) f= (if t~0 then ti1 el se t~2 )e
iff (C, P> F= t~0 1\
(C, P> F= til 1\ (c, P> F= t~2 1\
c(tl) ~ c(t) 1\ C(l2) ~ C(l)
[let] (C, P) f= (let x = ti1 in t~2 )e
iff (c, P> F= til 1\ (C, ?) F= t~2 1\
C(lt) ~ ?(x) 1\ C(l2) ~ c(t)
[ opJ (C, P> F= (til op t~2 )t iff (C, P> F= til 1\ (C, ?) F= t~2
Table 3.1: Abstract Control Flow Analysis (Subsections 3.1.1 and 3.1.2).
Acceptability relation. It remains to determine whether or not a

proposed guess (C, P) of an analysis results is in fact an acceptable 0-CFA
analysis for the program considered. We shall give an abstract specification
of what this means; having studied its theoretical properties (in Section 3.2)
we then consider how to compute the desired analysis (in Sections 3.3 and
3.4).
It is instructive to point out that the abstract specification corresponds to an
implicit formulation of the data flow equations of Chapter 2; it will be used
to determine whether or not a a guess is indeed an acceptable solution to
the analysis problem. The syntax directed and constraint based formulations
(of Sections 3.3 and 3.4) correspond to explicit formulations of the data fl.ow
equations from which an iterative algorithm in the spirit of Chaotic Iteration
(Section 1. 7) can be used to compute an analysis result.
For the formulation of the abstract 0-CFA analysis we shall write

(C,{J) F= e
for when (C, p) is an acceptable Control Flow Analysis of the expression e.
Thus the relation "f=" has functionality
F : (c;cile X ~ X Exp) ---) { true, false}
and its defining clauses are given in Table 3.1 (writing "always" for "iff true");
the clauses are explained below but the relation f= will not be formally defined
until Subsection 3.1.2.
The clause [con] places no demands on C(C) because we are not tracking
any data values in the pure 0-CFA analysis considered here and because we
assume that there are no functions among the constants; the clause can be
reformulated as
(C, p) F= ce iff 0 ~ c(c)
thereby highlighting this point.
The clause [var] is responsible for linking the abstract environment into the
abstract cache: so in order for (C, P) to be an acceptable analysis, everything
the variable x can evaluate to has tobe included in what may be observed
at the program point C: p(x) ~ C(C).
The clauses [fn] and [!un] simply demand that in order for (C, p) to be an
acceptable analysis, the functional term (fn x => ea or fun f x => ea) must
be included in C(C); this says that the term is part of a closure that can arise
at pro~ram point Cduring evaluation. Note that these clauses do not demand
that (C, p) is an acceptable analysis result for the bodies of the functions; the
clause for function application will take care of that.
Before turning to the more complicated clause [app] let us consider the clauses
[i~ and [let]. They contain "recursive calls" demanding that subexpressions
must be analysed in consistent ways using (C, p); additionally, the clauses
explicitly link the values produced by subexpressions to the value of the
overall expression, and in the case of [let] also the abstract cache is linked
into the abstract environment. The interplay between the clauses [var] and
[let] is illustrated in Figure 3.1; as in Chapter 2 an arrow indicates a flow of
information. The clause [op] follows the same overall pattern.
Clause [app] also contains "recursive calls" demanding that the operator 1 ti
and the operand t~2 can be analysed using (C, p). For each term fn x => t~0
that may reach the operator position (Cl), i.e. where
(fn X=> t~0 ) E C(C1)
it further demands that the actual parameter (labelled C2 ) is linked to the
formal parameter (x)
c p
~
(let x - tll in t~2)l
'"
1 - 1 1
[ ' '
'S::: l
Hl
A
1 1t~21
A
~
'- - - - - -' '- - -
Figure 3.1: Pictorial illustration of the clauses [let] and [var].
and that the result of the function evaluation (labelled fo) is linked to the
result of the application itself (labelled f)
and finally, that the function body itself can be analysed using (C, P):
This is illustrated in Figure 3.2. For terms fun f x => t~0 the demands are
much the same except that the term itself additionally needs to be included
in p(f) in order to refl.ect the recursive nature of fun f x => t~0 •
Example 3.5 Consider Example 3.3 and the guesses of a 0-CFA analysis
for the expression. First we show that (Ce, Pe) is an acceptable guess:
Using clause [app] and Ce(2) = {fn x => x 1 } we must check:

(Ce, Pe) F (fn X => x 1 ) 2
(Ce, Pe) F (fn Y => y 3 ) 4
(Ce, Pe) F X 1
Ce(4) ~ Pe(x)
Ce(l) ~ Ce(5)
1..-.........-.._...'"'-'"""-''...................................-.......-.................... 1 "
( fn X =>
1
t~0 ) 1 tf
A
1
1 1t~2 1----------.
A
lt~l----------~-'--'~----~
A
L - - - - -' L - -
L - - xl'~--~------------------------------------~
Figure 3.2: Pictorial illustration of the clauses [app], [fn] and [var].
All of these are easily checked using the clauses [fn] and [var].
Next we show that (C~, ?.,) is not an acceptable guess:
We do so by proceeding as above and observing that C~(4) ~ P'.,(x). •
Note that the clauses contain a number of inclusions of the form
lhs ~ rhs
where rhs is ofthe form C(i) or p(x) and where lhs is ofthe form C(l), p(x), or
{t}. These inclusions express how the higher-order entities may flow through
the expression.
It is important to observe that the clauses [fn] and [tun] do not contain
"recursive calls" demanding that subexpressions must be analysed. Instead
one relies on the clause [app] demanding this for all "subexpressions" that
may eventually be applied. This is a phenomenon common in program anal-
ysis, where one does not want to analyse unreachable program fragments:
occasionally results obtained from these parts of the program can suppress
transformations in the reachable part of the program. It also allows us to
deal with open systems where functions may be supplied by the environment;
this is particularly important for languages involving concurrency. However,
note that this perspective is different from that of type inference, where even
unreachable fragments must be correctly typed.
In the terminology of Section 2.5 the analysis is ftow-insensitive because FuN
contains no side effects and because we analyse the operand to a function call
even when the operator cannot evaluate to any function; see Exercise 3.3 for
how to improve on this. Also the analysis is context-insensitive because it
treats all function calls in the same way; we refer to Section 3.6 for how to
improve on this.
3.1.2 Well-definedness of the Analysis

Finally, we need to clarify that the clauses of Table 3.1 do indeed define a
relation. The difficulty here is that the clause [app] is not in a form that
allows us to define (C, p) f= e by structural induction in the expression e -
it requires checking the acceptability of (C, p) for an expression t~0 that is
not a subexpression of the application (tf 1 t~2 )~'. This leads to defining the
relation "f=" of Table 3.1 by coinduction, that is as the greatest fixed point of
a certain functional. An alternative will be to define the analysis as the least
fixed point of the functional but, as we shall see in Example 3.6 and more
formally in Proposition 3.16, this is not always appropriate.
The formal definition of f=.

Following the approach of Appendix
B we shall view Table 3.1 as defining a function:
Q : ((c;clle X ~ X Exp) ---+ { true, false})

---+ ( ( c;clle X ~ X Exp) ---+ { true, false})
As an example we have:
Q(Q)(C, p, (let x = tf1 in t~2 )')

= Q(C,fi,tf 1 ) 1\ Q(C,fi,t~2 ) 1\ C(J\) ~ fi(x) 1\ C(i2) ~ c(t)
We frequently refer to Q as a functional because its argument and result are

themselves functions.
Now by inspecting Table 3.1 it is easy to verify that the functional Q con-
structed this way is a monotone function on the complete lattice
((c;clle X ~ X Exp) ---+ { true,false}, ~)
where the ordering ~ is defined by:
Hence Q has fixed points and we shall define "f=" coinductively:

~ is the greatest fixed point of Q
The following example intuitively motivates the use of a coinductive (i.e. a

greatest fixed point) definition as opposed to an inductive (i.e. a least fixed
point) definition; a more formal explanation will be given in Subsection 3.2.4.
Example 3.6 Consider the expression loop of Example 3.4
(let g = (fun f x => (f 1 (fn y => y 2)3)4)5

in (g6 (fn z => z7)8)9)10
and the suggested analysis result (Cip, Pip)· To show (Cip, Plp) ~ loop it is,
according to the clause [let], sufficient to verify that
(C1p, Pip) ~ (fun f x => (f 1 (fn y => y 2 n 4)5
(Cip,Pip) ~ (g6 (fn z => z7)8)9
because Clp(5) ~ Pip(g) and Clp(9) ~ C1p(lO). The first clause follows from
[fun] and for the second clause we use that C1p(6) = {f} so it is, according to
[app], sufficient to verify that
because C1p(8) ~ Pip(x), Clp(4) ~ Clp(9) and f E Pip(f). The first two clauses
now follow from [var] and [fn]. For the third clause we proceed as above and
since Clp(1) = {f} it is sufficient to verify
(C1p, Plp) ~ f 1
(C1p, Pip) ~ (fn y => y 2 ) 3
(Cip,Pip) ~ (fl (fn y => y2)3)4
because Clp(3) ~ Pip(x), Clp(4) ~ Clp(4) and f E Pip(f).

Again the first two clauses are straightforward but in the last clause we
encounter a circularity: to verify (Cip, Pip) ~ (f 1 (fn y => y 2 ) 3 ) 4 we have
to verify (C 1p,Pip) ~ (f 1 (fn y => y2)3)4!
To solve this we use coinduction: basically this amounts to assuming that
(Cip, Pip) ~ (f 1 (fn y => y2 ) 3 ) 4 holds at the "inner level" and proving that
it also holds at the "outer level". This will give us the required proof. •
Analogy. The use of coinduction and induction, or greatest and least

fixed points, may be confusing at first. We therefore offer the following anal-
ogy. Imagine a company that is about to buy a large number of computers.
To comply with national and international rules for commerce the deal must
be offered in such a way that all vendors have a chance to make a bid. To
this effect the company first makes a specification of the requirements to the
computers (like the ability to execute certain benchmarks efficiently); how-
ever, the specification is necessarily loose meaning that there might be many
ways of fulfilling the requirements. Among the bids made the company then
chooses the bid believed tobe best (in the sense of offering the required func-
tionality as cheaply as possible or offering as much functionality as possible).
Then suppose that when the actual computers are delivered the company
suspects that they are not fulfilling the promises. It then starts arbitration
in order to persuade the vendor that they have not fulfilled their obligations
(and must take back the computers, or upgrade them or sell them at reduced
price). In order for the company to be successful it must be able to use
the details of the specification, and not any other information about what
other vendors would have been able to provide, in order to prove that the
computers delivered fail to fulfil one or more demands explicitly put forward
in the specification. If the specification is too loose, like just demanding an
Intel-based PC, there is no way that the inability to run Linux (or some other
operating system) can be used against the vendor. - Coming back to the
analysis in Table 3.1 its primary purpose is to provide a specification of when
a potential analysis result is acceptable. The specification takes the form of
defining a relation
f=: (C~e x &v x Exp)---+ {true,false}

and since the specification is intended to be loose it must be defined coin-
ductively: something only fails to live up to the specification if it can be
demonstrated to follow from the clauses; this line of reasoning is in fact
a fundamental ingredient in algebraic specification theory. As an example,
suppose we were silly and merely defined
(C,p) Fp iff (C,p) Fp

then any solution (C, p) would in fact li ve up to the specification; it is a simple
mathematical fact that only the coinductive interpretation of the definition of
f= willlive up to this demand (and in particular the inductive definition will
not as it will not accept any solutions at all). Having clarified the meaning of
the specificat ion we can then look for the best solution (C, p): this is typically
the least solution that satisfies the specification. So to summarise, the actual
specification itself is defined by a greatest fixed point (namely coinductively)
whereas algorithms for computing the intended solution are normally defined
by least fixed points.
3.2 Theoretical Properties

In this section we shall investigate some more theoretical properties of the
Control Flow Analysis, namely:
• semantic correctness, and
• the existence of least solutions.
The semantic correctness result is important since it ensures that the infor-
mation from the analysis is indeed a safe description of what will happen
during the evaluation of the program. The result about the existence of least
solutions ensures that all programs can be analysed and furthermore that
there is a "best" or "most precise" analysis result.
As in Section 2.2, the material of this section may be skimmed through on a
first reading; however, we reiterate that it is frequently when conducting the
correctness proof that the final and subtle errors in the analysis are found
and corrected!

Configurations. We shall equip the language FUN with a Structural
Operational Semantics. We shall choose an approach based on explicit envi-
ronments rather than substitutions because (as discussed in the Concluding
Remarks) a substitution based semantics does not preserve the identity of
functions (and hence abstract values) during evaluation. So a function defini-
tion will evaluate to a closure containing the syntax of the function definition
together with an environment mapping its free variables to their values. For
this we introduce the following categories
v E Val values
p E Env environments
defined by:
V c 1 close t in p
p .. - [ ] 1 p[x t--+ v]
A function abstraction fn x => eo will then evaluate to a closure, written

close (fn x => eo) in p; similarly, the abstraction fun f x => eo will evaluate
to close (fun f x => e0 ) in p. Our definitions do not demand that all terms t
occurring in some el o se t in p in the semantics will be of the form fn x => e0
or fun f x => eo; however, it will be the case for the semantics presented
below.
As in Section 2.5 we shall need intermediate configurations to handle the

binding of local variables. We therefore introduce syntactic categories for
intermediate expressions and intermediate terms
ie E IExp intermediate expressions
it E ITerm intermediate terms
that extend the syntax of expressions and terms as follows:
ie .. - itl
it c 1 x 1 fn x => eo 1 fun f x => eo 1 ie1 ie2

i f ieo then e1 else e2 llet x = ie1 in e2 1 ie1 op ie2
bind p in ie 1 close t in p
The role of the bind-construct is much as in Section 2.5: bind p in ie records

that the intermediate expression ie has to be evaluated in an environment
with the bindings p. (The sequence of environments of nested bind-constructs
may be viewed as an encoding of the frames of a run-time stack.) So while
close t in p is a fully evaluated value this is not the case for bind p in ie.
We shall need these intermediate terms because we define a small step se-
mantics; only the close-constructs will be needed for a big step variant of
the semantics.
Alternatively, the definitions of Val and Env could have been written Val =
Const+ (Term x Env) and Env =Var ---+fin Val (for a finite mapping) but
it is important to stress that all entities are defined mutually recursively in
the manner of context-free grammars. Formally, we defined an environment p
as a list but nevertheless we shall feel free to regard it as a finite mapping: we
write dom(p) for {x 1 p contains [x ~ · · ·]}; we write p(x) = v if x E dom(p)
and the rightmost occurrence of [x ~···]in p is [x ~ v], and we write piX
for the environment obtained from p by removing all occurrences of [x ~ · · ·]
with x rţ X. For the sake ofreadability we shall write [x ~ v] for [ ][x ~ v].
We have been very deliberate in when to use intermediate expressions and
when to use expressions although it is evident that all expressions are also
intermediate expressions. Since we do not evaluate the body of a function
before it is applied we continue to let the body be an expression rather
than an intermediate expression. Similar remarks apply to the branches of
the conditiona} and the body of the local definitions. Note that although
an environment only records the terms fn x => eo and fun f x => eo in the
closures bound into it, we do not Iose the identity of the function abstractions
as e0 will be of the form t~0 and hence lo may be used as the "unique"
identification of the function abstraction.
'Ii'ansitions. We are now ready to define the transition rules of the Struc-
tural Operational Semantics by means of judgements of the form
p 1- ie 1 ---+ ie2
[var] p f- xl--+ vl if x E dom(p) and v = p(x)
[fn] p f- (fn x => eo)l--+ (close (fn x => eo) in po)l

where Po = p 1 FV(fn x => eo)
[tun] p f- (fun f x => eo)l--+ (close (fun f x => eo) in Po)l

where Po = p 1 FV(fun f x => eo)
p f- (ie1 ie2)e --+ (ie~ ie2)l

p f- ie2 --+ ie~
p f- (vÎ 1 ie2)l--+ (vf 1 ie~)l
p f- ((close (fn x => e1) in Pd 1 v~ 2 / --+

(bind Pl [x f-t v2] in el)l
p f- ((close (fun f x =>e1) in pl)f 1 v~ 2 )e --+

(bind P2[x f-t v2] in ed
where P2 = Pl [/ f-t close (fun f x => e1) in Pl]
[bind1]
p f- (bind Pl in iel)l --+ (bind Pl in iei)l
p f- (bind Pl in vf 1 )l --+ vf
Table 3.2: The Structural Operational Semantics of FUN (part 1).
given by the axioms and inference rules of Tables 3.2 and 3.3; they are ex-
plained below. The idea is that one step of computation of the expression
ie 1 in the environment p will transform it into ie2.
The value of a variable is obtained from the environment as expressed by the
axiom [var]. The axioms [fn] and [!un] construct the appropriate closures;
they restrict the environment p to the free variables of the abstraction. Note
that in [tun] it is only recorded that we have a recursively defined function;
the unfolding of the recursion will not happen until it is called.
The clauses for application shows that the semantics is a call-by-value seman-
tics: In an application we first evaluate the operator in a number of steps
using the rule [app 1 ] and then we evaluate the operand in a number of steps
using the rule [app2]. The next stage is to use one of the rules [apptnl or
[ appfun] to bind the actual parameter to the formal parameter and, in the
case of [appfunl, to unfold the recursive function so that subsequent recursive
calls will be bound correctly. We shall use a bind-construct to contain the
body of the function together with the appropriate environment. Finally, we
p f- ieo ---+ ie~

[ifrJ
p f- ( if ieo then e1 el se e2)C ---+ ( if ie~ then e1 el se e2)c
p f- ( if truefo then tÎ 1 el se t~2 )c ---+ ti
p f- (if falseco then tÎ 1 else t~2 )c---+ t~
p f- (let x = ie1 in e2)c ---+ (let x = ie~ in e2)C

p f- (let x = vc 1 in e2)e---+ (bind Po[x ~----+ v] in e2l
where Po = p FV(e2) 1
p f- ( ie1 op ie2 )f ---+ (ie~ op ie2 )f

p f- ie2 ---+ ie~
Table 3.3: The Structural Operational Semantics of FuN (part 2).
evaluate the bind-construct using rule [bind1] a number of times, and we get
the result of the application by using rule [bind2 ]. The interplay between
these rules is illustrated by the following example.
Example 3. 7 Consider the expression ((fn x => x 1)2 (fn y => y 3 ) 4 ) 5 of

Example 3.1. It has the following derivation sequence (explained below):
[] f- ((fn x => xl)2 (fn y => y3)4)5

---+ ((close (fn x => x 1) in [ ]) 2 (fn y => y3 ) 4 ) 5
---+ ((close (fn x => x 1) in [ ]) 2 (close (fn y => l) in [ ]) 4 ) 5
---+ (bind [x ~----+ (close (fn y => y 3 ) in [])]in x 1) 5
---+ (bind [x ~----+ ( close (fn y => y 3 ) in [ ]) ] in
(close (fn y => y 3 ) in [ ]) 1)5
---+ (close (fn y => y 3 ) in [ ]) 5
First [app 1] and [fn] are used to evaluate the operator, then [app2] and lfn]
are used to evaluate the operand and [aPPJn] introduces the bind-construct
containing the local environment [x ~----+ (el o se (fn y => y 3 ) in [ ]) ] needed
to evaluate its body. So x 1 is evaluated using [bind1] and [var], and finally
[bind2 ] is used to get rid of the local environment. •
The semantics of the conditiona! is the usual one: first the condition is eval-
uated in a number of steps using rule [ift] and then the appropriate branch
is selected by rules [ih] and [i!J]. For the local definitions we first compute
the value of the bound variable in a number of steps using rule [let1] and
then we introduce a bind-construct using rule [let2] refl.ecting that the body
of the let-construct has to be evaluated in an extended environment. The
rules [bind1] and [bind2] are now used to compute the result. For binary ex-
pressions we first evaluate the arguments using [op 1 ] and [op2 ] and then the
operation itself, denoted op, is performed using [op3 ].
As in Chapter 2 the labels have no impact on the semantics but are merely
carried along. It is important to note that the outermost labei never changes
while inner labels may disappear; see for example the rules [ih] and [bin~].
This is an important property of the semantics that is exploited by the 0-CFA
analysis.
Example 3.8 Let us consider the expression, loop
(let g = (fun f x => (f 1 (fn y => y2)3)4)5

in (g6 (fn z => z7)8)9)10
of Example 3.2 and see how the informal explanation of its semantics is
captured in the formal semantics. First we introduce abbreviations for three
closures:
f close (fun f x => (f 1 (fn y => y 2 ) 3 ) 4 ) in []

idy close (fn y => y 2 ) in [ ]
idz close (fn z => z 7 ) in []
Then we have the following derivation sequence
[] f- loop
--t (let g = f 5 in (g6 (fn z => z 7)8)9)10
--t (bind [g ~ f] in (g 6 (fn z => z 7 ) 8 ) 9 ) 10
--t (bind [g ~ f] in (f 6 (fn z => z 7 ) 8 ) 9 ? 0
--t (bind [g ~ f] in (f6 id~) 9 ) 10
--t (bind [g ~ f] in
(bind [f ~ f][x ~ idz] in (f 1 (fn y => y2)3) 4)9) 10
--t* (bind [g ~ f] in
(bind [f ~ f][x ~ idz] in
(bind [f ~ f][x ~ idy] in (fl (fn y => y2)3)4)4)9)10
showing that the program does indeed loop. •

[bind] (C, P) f= (bind p in it~0 )~'

iff (c, {J) F= it~0 1\ c(to) ~ c(t) 1\ P n {J
[clase] (C, P) f= (close to
in p )~'
iff {to} ~ C(i) 1\ p n jJ
Table 3.4: Abstract Control Flow Analysis for intermediate expressions.
3.2.2 Semantic Correctness

We shall formulate semantic correctness of the Control Flow Analysis as a
subject reductian result; this is an approach borrowed from type theory and
merely says that an acceptable result of the analysis remains acceptable under
evaluation. However, in order to do that we need to extend the analysis to
intermediate expressions.
Analysis of intermediate expressions. The clauses for the con-

structs bind p in ie and close to in p are given in Table 3.4; the remaining
clauses are as in Table 3.1 (with the obvious replacements of expressions with
intermediate expressions).
The clause [bind] reflects that its body will be executed and hence whatever
it evaluates to will also be a possible value for the construct. Additionally, it
expresses that there is a certain relationship n between the local environment
(of the semantics) and the abstract environment (of the analysis). The clause
[clase] is similar in spirit to the clauses for function abstraction: the term of
the closure is a possible value of the construct. Additionally, there has tobe
a relationship n between the two environments.
Correctness relation. The purpose of the global abstract environ-

ment, p, is to model all of the local environments arising during evaluation.
We formalise this by defining the carrectness relatian
n : (Env X ~) true,Ealse} --t {
and demanding that p n p for all local environments, p, occurring in the

intermediate expressions. We then define:
p 'R p iff dom(p) ~ dom(p) 1\ Vx E dom(p) '<ltx '<lpx :

(p(x) = close tx in Px) =* (tx E p(x) 1\ Px 'R P)
This clearly demands that the function abstraction, tx, in p(x) must be an
element of p(x). It also shows that aU local environments reachable from p,
e.g. Px, must be modelled by pas well. Note that the relation n is well-
defined because each recursive call is performed on a local environment that
-+ ie' -+ ie" -+
[~ [~
(C,{J) (C,{J) (c, P)
Figure 3.3: Preservation of analysis result.
is strictly smaller than that of the call itself; thus a simple proof by well-
founded induction (Appendix B) suffices for showing the well-definedness of
n.
Example 3.9 Suppose that:
p [x ~ close tt in Pt] [y ~ close t2 in P2]
Pt []
P2 [x ~ close t3 in P3]
P3 = []
Then p R p amounts to {tt, t3} ~ p(x) 1\ {t2} ~ p(y). •

We shall sometimes find it helpful to split the definition of n into two com-
ponents. For this we make use of the auxiliary relation
V : (Val x (:En; x Vai)) -+ { true, false}
and define V and n by mutual recursion:

vV(p,v) iff \it\ip:(v=closetinp)::::} (tEv 1\ pRP)
pR p iff dom(p) ~ dom(PJ 1\ \ix E dom(p) : p(x) V (p, p(x))
Clearly the two definitions of n are equivalent.
Correctness result. The correctness result is now expressed by:
Theorem 3.10
u P n {J and P f-ie-+ ie' then (c, PJ Fie implies (c, PJ Fie'.
This is illustrated in Figure 3.3 for a terminating evaluation sequence p f-

ie -+* ve; note that the result is analogous to that of Corollary 2.17 for the
Live Variables Analysis in Chapter 2.
The intuitive content of the result is as follows:
If there is a possible evaluation of the program such that the

function at a call point evaluates to some abstraction, then this
abstraction has to be in the set of possible abstractions computed
by the analysis.
To see this assume that p f-- t€ ----+* ( close to in po)f and that (C, p) f= tf as
well as p R p. Then Theorem 3.10 (and an immediate numerical induction)
gives that (C, p) f= (el o se to in Po )€. Now from the clause [clase] of Table
3.4 we get that to E C(C) as was claimed. It is worth noticing that if the
program is closed, i.e. if it does not contain free variables, then p will be [ ]
and the condition p R p is trivially fulfilled.
Note that the theorem expresses that all acceptable analysis results remain
acceptable under evaluation. One advantage of this is that we do not need to
rely on the existence of a least or "best" solution (tobe proved in Subsection
3.2.3) in order to formulate the result. lndeed the result does not say that
the "best" solution remains "best" - merely that it remains acceptable. More
importantly, the result opens up the possibility that the efficient realisation
of Sections 3.3 and 3.4 computes a more approximate solution than the least
(perhaps using the techniques of Chapter 4). Finally, note that the formula-
tion of the theorem crucially depends on having defined the analysis for all
intermediate expressions rather than just all ordinary expressions.
We shall now turn to the proof of Theorem 3.10. We first state an important
observation:
Proof By cases on the clauses for "f=". •

We then prove Theorem 3.10:
Proof We assume that p R pand (C, {i) f= ie and prove (C, {i) f= ie' by induction
on the structure of the inference tree for p 1- ie ---+ ie'. Most cases simply amount
to inspecting the defining clause for (C, {i) f= ie; note that this method of proof
applies to all fixed points of a recursive definition and in particular also to the
greatest fixed point. We only give the proofs for some of the more interesting cases.
The case [var]. Here p 1- ie---+ ie' is:
p 1- xe---+ ve because x E dom(p) and v = p(x)

If v= c there is nothing to prove so suppose that v = close to in po. From p R p
we get v V (p, p( x)) and hence to E P( x) and po R p. From (C, {i) f= ie we get
p(x) ~ C(fl), and hence to E C(fl). Since to E C(fl) and poR pwe have established
(C, {i) f= ie'.
The case [In]. Here p r ie --> ie' is:
p f- (fn X=> ea)R--> (close (fn X=> ea) in pa)R

where pa = p FV(fn x => ea)
1
From (C, {i) f= ie we get (fn x => ea) E C(i'); from p R p it is immediate to get
pa R P., this then establishes (C, {i) f= ie'.
The case [app 1 ]. Here p r ie --+ ie' is:
p r (ie1 ie2 )R --> ( ie~ ie2 )R because p r ie1 --> ie~
The defining clauses of (C, {i) f= ie and (C, {i) f= ie' are equal except that the former
has (C, {i) f= ie1 where the latter has (C, {i) f= ie~. From the induction hypothesis
applied to
(C, {i) F iel' p R and p r iel --> ie~ p,
we get (C, {i) f= ie~ and the desired result then follows.
The case [appfnl· Here p r ie --+ ie' is:
From (C, {i) f= ie we have (C, {i) f= (close (fn x => tg 0 ) in pd 1 which yields:
Further we have (C, {i) f= v; 2 ; in the case where V2 = c, it is immediate that
and in the case where V2 = close t2 in p2 it follows from the definition of (C, {i) f=
v~ 2 • Finally, the first universally quantified formula of the definition of (C, {i) f= ie
gives:
tg
(C,{i) f= 0 , C(i'2) <:;; p(x), and C(i'a) <:;; C(i')
Now observe that V2 V (P,p(x)) since C(i'2) <:;; p(x) follows from the clause (app1n).
Since Pl R p we now have
and this establishes the desired (C, {i) f= ie'.

The case [bind2]. Here p r ie--+ ie' is:
p r (bind Pl in vf 1 )R --> vf
R
f= ie we have (C, {i) f= v11 as well as C(i'1) <:;; C(i') and the desired
~ ~
From (C, {i)

~
(C, {i) f= vf follows from Fact 3.11.

This completes the proof. •
Example 3.12 From Example 3.7 we have:

[] f- ((fn x => x 1 ) 2 (fn y => y 3 ) 4 ) 5 --+* (close (fn y => y 3 ) in [ ]) 5
Next let (Ce, Pe) be as in Example 3.3. Clearly [ l n Pe and from Example
3.5 we have:
According to Theorem 3.10 we can now conclude:
Using Table 3.4 it is easy to check that this is indeed the case. •
3.2.3 Existence of Solutions
Having defined the analysis in Table 3.1 it is natural to ask the following
question: Does each expression e admit a Control Flow Analysis, i.e. does
there exist (C, j5) such that (C, j5) f= e? We shall show that the answer to this
question is yes.
However, this does not exclude the possibility of having many different analy-
ses for the same expression so an additional question is: Does each expression
e have a "least" Control Flow Analysis, i.e. does there exists (Co, po) such
that (Co, Po) f= e and such that whenever (C, j5) f= e then (Co, po) is "less
than" (C, p)? Again, the answer will be yes.
Here "least" is with respect to the partial order defined by:
(C1,p1) ~ (C2,p2) iff (Vf E Lab: C1(i) ~ C2(i)) A

(Vx E Var: Pl(x) ~ P2(x))
It will be the topic of Sections 3.3 and 3.4 (and Mini Project 3.1) to show that
the least solution can be computed efficiently for all expressions. However, it
may be instructive to give a general proof for the existence of least solutions
also for intermediate expressions. To this end we recall the notion of a Moare
family (see Appendix A and Exercise 2.7):
A subset Y of a complete lattice L = (L, ~) is a Moore family if

and only if (n Y') E Y for all Y' ~ Y.
This property is also called the model intersection property because whenever
we take the "intersection" of a number of "models" we still get a "model" .
Proposition 3.13
For all ie E IExp the set {(C, P) 1 (C, p) f= ie} is a Moore family.
It is an immediate corollary that all intermediate expressions ie admit a

Control Flow Analysis: Let Y' be the empty set; then nY' is an element of
{(C, p) 1(C, p) f= ie} showing that there exists at least one analysis of ie.
It is also an immediate corollary that all intermediate expressions have a least
Control Flow Analysis: Let Y' be the set {(C, p) 1(C, P) Fie}; then nY' is
an element of { (C, P) 1(C, p) f= ie} so it will also be an analysis of ie. Clearly
nY' !:"; (C, P) for an other analyses (C, P) of ie so it is the least analysis result.
In preparation for the proof of Proposition 3.13 we shall first establish an
auxiliary result for n and V:
Lemma 3.14
(i) For all pE Env the set {p 1 p n p} is a Moore family.
(ii) For all V E Val the set { (p, v) 1V V (p, v)} is a Moore family. •
Proof To prove (i) we proceed by well-founded induction on p (which is also the
manner in which the existence of the predicate was proved). Now assume that
ViEI: p R {i;
for some index set I and let us show that p R (n;p;). For this consider x, tx, and
Px such that:
p(x) = close tx in Px
We then know
ViEI: tx E Pi(x)
Px R Pi
1\
and using the induction hypothesis it follows that
tx E (niPi)(x) 1\ Px n (niPi)
(taking care when I = 0).
To prove (ii) we simply expand the definition of V and note that the result then
follows from (i). •
We now prove Proposition 3.13 using coinduction (see Appendix B):

Proof The ternary relation 1= of Tables 3.1 and 3.4 is the greatest fixed point of
a function Q as explained in Section 3.1. Now assume that
ViEI: (C;,pi) 1= ie
and let us prove that n;(C;,pi) 1= ie. We shall proceed by coinduction (see Ap-
pendix B) so we start by defining the ternary relation Q' by:
(C',{J)Q'ie' iff (C',iJ)=ni(ci,{i;) A ViEI:(Ci,Pi)l=ie'

It is then immediate that we have:
The coinduction proof principle requires that we prove
Q' [;:;; Q(Q')
and this amounts to assuming (C', jl) Q' ie' and proving that (C', jl) ( Q(Q')) ie'.
So let us assume that
ViEI: (C;,,Pi) != ie'
and let us show that:
il;(c;, Pi) (Q(Q')) ie'
For this we consider each of the clauses for ie' in turn.
Here we shall only deal with the more complicated choice ie' = (itÎ 1 it; )e. From
2
ViEI: (C;,p;) != (itÎ 1 it~2 )e

we get Vi E I : (C;, p;) != itÎ 1 and hence:
Similarly we get:
f ~
Next consider (fn X=> ta0 ) E ni(C;(.el)) and let us prove that:
For ali i E I we have that (C;, p;) != ie' and since (fn x => t~0 ) E C; (.e!) we have
and this then gives (3.1) as desired (taking care when I = 0). The case of
(fun f x => t~0 ) E n;(C;(RI)) is similar. This completes the proof. •
Example 3.15 Let us return to Example 3.5 and consider the following
potential analysis results for ((fn x => x1)2 (fn y => y3) 4)5:
(Ce, Pe) (c~, ~) (c~, fi::)

1 {fn y => y;j} {fn y => y;j} {fn y => y;j}
2 {fn x => x 1 } {fn x => x 1 } {fn x => x 1 }
3 0 {fn x => x 1 } {fn y => y 3 }
4 {fn y => y 3 } {fn y => y 3 } {fn y => y 3 }
5 {fn y => y 3 } {fn y => y 3 } {fn y => y 3 }
X {fn y => y 3 } {fn y => y 3 } {fn y => y 3 }
y 0 {fn x => x 1 } {fn y => y 3 }
It is straightforward to verify that
(C~,~) F=((fn x => x1)2 (fn y => y3)4)5

(C~,f5::) F ((fn x => x1)2 (fn y => y3)4)5
Now Proposition 3.13 ensures that also:
(C~nc~.~n~) F ((fn X=> x1) 2 (fn y => y3)4)5
Neither (C~, ~) nor (C~, f5::) is a least solution. Their "intersection" (C~ n
c~, ~ n P::) is smaller and equals (c.,
p-.) which turns out to be the least
analysis result for the expression. •
3.2.4 Coinduction versus Induction

One of the important aspects of the development of the abstract Control
Flow Analysis in Table 3.1 is the coinductive definition of the acceptability
relation:
F= as the greatest fixed point of a functional Q
An alternative might be an inductive definition of an acceptability relation:
F=' as the least fixed point of the functional Q.
However, in Example 3.6 we argued that this might be inappropriate and

here we are going to demonstrate that an important part of the development
of the previous subsection actually fails for the least fixed point (F=') of Q.
Proposition 3.16
There exists e* E Exp such that { (C, p) 1(C, p) F=' e*} is not a
Moore family.
Proof ( sketch) This proof is rather demanding and is best omitted on a first
reading. To make the proof tractable we consider
e* t;
t* = (fn x => (xl xl)l)l (fn x => (xl xl)l)l
and take:
Labe {f}
Var. {x}
Term. {t*,fnx=> (xl xl)t,xl xt,x}
lE~. {ti 1 tE Term.}
Val. P( { fn x => (xl xl)l}) = {0, {fn x => (xl xl)l}}
This is in line with Exercise 3.2 (and the development of Subsection 3.3.2) and as
we shall see the proof of Proposition 3.13 is not invalidated.
Next let Q be the functional defined by Table 3.1 and let Q be in the domain of Q.
The condition
Q = Q(Q)
is equivalent to:
Vt E Terrr1., : V(C, {i) : ( (C, {i) Q te iff (C, {i) Q( Q) l)
By considering the four possibilities of t E Terme this is then equivalent to the

conjunction of the following four conditions (where (C, {i) is universally quantified):
(C, {i) Q xc iff p(x) <:;; C(P)
(C, {i) Q (fn x => (xc xc)e)c iff {fn x => (xe xen <:;; C(P)
(C, {i) Q (xc xf)f iff (C, {i) Q xf 1\
C(P)-:f-0 => ((C,{i)Q(xcxc)cl\

C(P) <:;; p(x))
(C, PJ Q t! iff (C, {i) Q (fn x => (xf xf)f)f (\

C(P) -:f. 0 => ( (C, {i) Q (xe xe)e 1\
C(P) <:;; p(x))
~ ~ f
Here we have used th~(P) -:f. 0 implies that C(P) = {fn x => (x xe)c} as follows
from the definition of Vale in the beginning of this proof.
The conjunction of the above four conditions implies the conjunction of the following
four conditions:
(C, {i) Q xe iff p(x) <:;; C(P)
(C, {i) Q (fn x => (xe xf)f)f iff {fn x => (xc xc)e} <:;; C(P)
(C, {i) Q (xc xc)c iff p(x) <:;; C(P) 1\
(C(P) i=- 0 => (C, {i) Q (xe xc)e) A
C(P) <:;; p(x)

f f f ~
{fnx=> (x x) }<:;;C(P) 1\
(C, PJ Q (xc xc)c 1\
C(P) <:;; p(x)
This implication can be reversed and this shows that also the conjunct of the above
four conditions is equivalent to Q = Q(Q).
Using that p(x) can only be 0 or {fn x => (xc xc)c}, and similarly for C(P), the
above four conditions are equivalent to the following:
(C,P) Q (fn X=> (xf xf)f)f iff {fn X=> (xf xcn = C(R)
(C, P) Q (x€ xc)c iff p(x) = C(R) 1\
(C(R) i- 0 ~ (C, P) Q (xc xc)c)
(C,P) Q t: iff {fn X=> (xf xcn = C(R) = p(x) 1\
(C, P) Q (xc xc)c

It follows that the conjunct of the above four conditions is once more equivalent to
Q = Q(Q).
The crucial case in the definition of (C, P) Q e is for e = (xc xc)c as this determines
the truth or falsity of ali other cases. We shall now try to get a handle on the
candidates Q1, · · ·, Qn for satisfying Q; = Q( Q;). Concentrating on the condition
for (xc xc)c it follows that (C, P) Q; (xc xc)c must demand that C(R) = p(x). Since
each of C(R) and p(x) can only be {fn x => (xc xc)c} or 0 there are at most the
following four candidates for Q;:
(C, P) Q1 (xc xc)c iff C(R) = p(x)

(C, P) Q2 (xc xc)c iff C(R) = p(x) = 0
(C, P) Q3 (xc xc)c iff C(R) = p(x) of. 0
(C, P) Q4 (xc xc)c iff false
Verifying the condition

~ f f f
V(C, P) : ( (C, P) Q; (x x )
for i E {1, 2, 3, 4} it follows that Q1 and Q2 satisfy the condition whereas Q3 and
Q4 do not.
It is now straightforward to verify also the remaining three conditions and it follows
that:
Q; = Q(Q;) for i = 1,2
This means that Q1 equals f= (the greatest fixed point of Q) and that Q2 equals
f=' (the least fixed point of Q). One can then calculate that
(c, P) Q1 t! iff c(e) = ;J(x) -1- 0
(C, P) Q2 t: iff false
and this shows that
which is a singleton set and in fact a Moore family, whereas
which cannot be a Moore family (since a Moore family is never empty). This
completes the proof. •
3.3 Syntax Directed 0-CFA Analysis

We shall now show how to obtain efficient realisations of 0-CFA analyses. So
assume throughout this section that e* E Exp is the expression of interest
and that we want to find a "good" solution (C, p) satisfying (C, p) f= e*.
This entails finding a solution that is as small as possible with respect to the
partial order ~ defined in Section 3.2 by:
Proposition 3.13 shows that a least solution does exist; however, the algo-
rithm that is implicit in the proof does not have tractable (i.e. polynomial)
complexity: it involves enumerating all candidate solutions, determining if
they are indeed solutions, and if so taking the greatest lower bound with
respect to the others found so far.
An alternative approach is somehow to obtain a finite set of constraints, say
of the form lhs ~ rhs (where lhs and rhs are much as described in Section
3.1), and then take the least solution to this system of constraints. The
most obvious method is to expand the formula (C, p) f= e* by unfolding
all "recursive calls", using memoisation to keep track of all the expansions
that have been performed so far, and stopping the expansion whenever a
previously expanded call is re-encountered.
Three phases. We shall take a more direct route motivated by the above
considerations; it has three phases:
(i) The specification of Table 3.1 is reformulated in a syntax directed man-

ner (Subsection 3.3.1).
(ii) The syntax directed specification is turned into an algorithm for con-
structing a finite set of constraints (Subsection 3.4.1).
(iii) The least solution of this set of constraints is computed (Subsection
3.4.2).
This is indeed a common phenomenon: a specification "f=A" is reformulated

into a specification "f=B" ensuring that
so that "f=B" is a safe approximation to "f=A" and in particular the best

(i.e. least) solution to "f=B e/' is also a solution to "f=A e*". This also
ensures that all solutions to "f=B" are semantically correct (assuming that
this has already been established for all solutions to "f=A"); however, we do
not claim that a subject reduction result holds for f= B ( even though it has
been established for f= A).
303 Syntax Directed 0-CFA Analysis 169
If additionally
(C, P) FA e* =} (C, p) i=B e*
then we can be assured that no solutions are lost and hence the best (i.eo least)
solution to "I==B e*" will also be the best (i.eo least) solution to "I==A e*" o As
we shall see, it may be necessary to restrict attention to only solutions (C, p)
satisfying some additional properties (eogo that only program fragments of e*
appear in the range of Cand p) o
3.3.1 Syntax Directed Specification

In reformulating the specification of "1= e*" into a more computationally
oriented specification "l=s e*" we shall ensure that each function body is
analysed at most once rather than each time the function could be appliedo
One way to achieve this is to analyse each function body exactly once as is
dane in the syntax directed 0-CFA analysis of Table 305; a better alterna-
tive would be to analyse only reachable function bodies and we refer to Mini
Project 301 for how to achieve thiso In Table 3o5 each function body is there-
fore analysed in the relevant clause for function abstraction rather than in
the clause for function application; thus we now risk analysing unreachable
program fragmentso
The formal definition of Fs·

Since semantic correctness was dealt
with in Section 302 there is no longer any need to consider intermediate
expressions and consequently aur specification of
(C, p) l==s e
in Table 305 considers ordinary expressions onlyo We shall take "l=s" to be
the largest relation that satisfies the specification; however, given the syntax
directed nature of the specification there is in fact only one relation that
satisfies the specification (see Exercise 309)0 Hence it would be technically
correct, but intuitively misleading, to claim that we take the least relation
that satisfies the specificationo In other words, whether or not 1= 8 is defined
inductively or coinductively, the same relation is defined; this is a common
phenomenon whenever the clauses are defined in a syntax directed manner.
Example 3.17 Consider the expression loop

(let g = (fun f x => (f 1 (fn y => y 2)3)4)5
in (g6 (fn z => z7)8)9)10
of Example 3.40 We shall verify that (Cip, /)ip) l=s loop where C1p and /)ip are
as in Example 3.40 Using the clause [let], it is sufficient to show
(Cip, /)ip) l=s (fun f x => (f 1 (fn y => y 2)3)4)5 (3o2)
(Cip, /)ip) l=s (g 6 (fn z => z 7 ) 8 ) 9 (303)
[con] (C,P) Fs d always

[var] (C,P) Fs xe iff p(x) ~ C(f)
ffn] (C, P) Fs (fn x => eo)e

iff {fn x => eo} ~ C(f) 1\
(C, p) Fs eo
[fim] (C, P) Fs (fun f x => eo)e
iff {fun f x => eo} ~ C(f) 1\
(C,p) Fs eo 1\ {fun f x => eo} ~ p(f)
[app] (C,P) Fs (tf t~2 )e

1
iff (C, P) F=s til 1\ (C, fi) F=s t~2 1\

(V(fn x => t~0 ) E C(fi) :
C(f2) ~ fi(x) 1\ C(fo) ~ C(f)) 1\
(\f(fun f x => t~0 ) E C(f1) :
C(P2) ~ fi(x) 1\ C(fo) ~ c(t))
[i.fl (C,P) Fs (if t~0 then tf1 else t~2 )e
iff (C, P) Fs t~0 1\
(c, P) F=s til A (c, fi) F=s t~2 A
c(ei) ~ C(f) 1\ C(f2) ~ c(e)
[let] (C,P) Fs (let x = tf 1 in t~2 )e
iff (C, P) F=s til A (C, fi) F=s t~2 A
C(f1) ~ fi(x) 1\ C(f2) ~ c(e)
[op] (C,P) Fs (tf1 op t~2 )e iff (C,P) Fs tf1 1\ (C,p) Fs t~2
Table 3.5: Syntax directed Control Flow Analysis.
since we have Clp(5) ~ Pip(g) and Clp(9) ~ C1p(lO). To show (3.2) we use the
clause [fim] and it is sufficient to show
since f E Clp(5) and f E Pip(f). Now C1p(l) = {f} so, according to clause [app]
this follows from
3.3 Synta.x Directed 0-CFA Analysis 171
since Cip(3) ~ ,Oip(x) and Cip(4) ~ Cip(4). The first clause follows from [var]
since ,Oip(f) ~ Cip(l) and for the last clause we observe that idy E Cip(3) and
(Cip, ,Oip) Fs y2 as follows from ,Oip(y) ~ Cip(2).
To show (3.3) we observe that Cip(6) = {f} so using [app] it is sufficient to
show
~
(Cip,,Oip) Fs g6
(Cip, Pip) Fs (fn z=> z )
~ ~ 7 8
since Cip(8) ~ ,Oip(x) and Cip(4) ~ Cip(9). This is straightforward except for
the last clause where we observe that idz E Cip(8) and (Cip,,Oip) Fs z 7 as
follows from ,Oip(z) ~ Cip(7).
Note that because the analysis is syntax directed we have had no need for
coinduction, unlike what was the case in Example 3.6. •
3.3.2 Preservation of Solutions

The specification of the analysis in Table 3.5 uses potentially infinite value
spaces although this is not really necessary (as Exercise 3.2 demonstrates
for Table 3.1). We can easily restrict ourselves to entities occurring in the
original expression and this forms the hasis for relating the results of the
analysis of Table 3.5 to those of the analysis of Table 3.1.
So let Lab* ~ Lab be the finite set of labels occurring in the program e* of
interest, let Var* ~ Var be the finite set of variables occurring in e* and let
Term* be the finite set of subterms occurring in e*. Define (CI, pi) by:
c; (c) ={ 0 Term*
if C f/:- Lab*
if CE Lab*
-p;(x) ={ 0 Term*
ifxf/:_Var*
if x E Var*
Then the claim
~ ~T T
(C,p) r;;;; (C* ,p*)
intuitively expresses that (C, p) is concerned only with subterms occurring in
the expression e*; obviously, we are primarily interested in analysis results
with that property. Actually, this condition can be "reformulated" as the
technically more manageable
where we define Cache* = Lab*--+ Val*, Env* =Var*--+ Vaî* and Vaî* =
P(Term*).
We can now show that all the solutions to "F=s e/' that are "less than"
(CJ, pi) are solutions to "f= e*" as well:
Proposition 3.18 T
Fs e* and (C, p) ~ (C*, p*) then (C, PJ f= e*.
~ ~ ~T ~
If (C, p)
T
Proof Assume that (c, P) F 8 e* and that (c, P) [;;;; (c* 'p* ). Furthermore let
~ ~T
Exp* be the set of expressions occurring in e* and note that
Ve E Exp*: (C,P) F• e (3.4)

is an immediate consequence of the syntax directed nature of the definition of F•·
To show that (C, P) f= e* we proceed by coinduction. We know that "f=" is defined
coinductively by the specification of Table 3.1, i.e. "f= = g.tp(Q)" where Q is the
function (implicitly) defined by Table 3.1. Similarly, we know that "F=s = g.tp(Q.)"
where Q. is the function (implicitly) defined by Table 3.5.
Next write (C',{J) f=* e' = (C,P) Ae' E Exp*. It now suffices to show
for (C',{J)
(Q.(f=.) n f=*) ~ Q(f=. n f=*) (3.5)
because then "(f=. n f=*) ~ Q(f=. n f=*)" follows and hence by coinduction
"(f=. n f=*) ~ f=" and since (C, P) F• e* as well as (C, P) f=* e* we then have the
required (C, P) f= e*.
The proof of (3.5) amounts to a comparison of the right hand sides of Table 3.5
and Table 3.1: for each clause we shall assume that the right hand side of Table
3.5 holds for (C, p, e) and that e E Exp* and we shall show that the corresponding
right hand side of Table 3:1 holds when all occurrences of "f=" are replaced by
"F=s n F*".
The clauses [con], [var], [i~, [let] and [op] are trivial as the right hand sides of Tab les
3.5 and 3.1 are similar and the subterms will all be in Exp*. The clauses [fn] and
[!un] are straightforward as the right hand sides of Table 3.5 imply the right-hand
sides of Table 3.1. Finally, we consider the clause [app]. For (fn x => t~0 ) E C(Rl)
we need to show that (C, P) F• t 0°; but since (C, P) [;;;; (C*, p*) this follows from
~ f ~ ~T T
(3.4). For (fun f x => t t0°) E -C(l\) we need to show that (C, -
P) F• t 0R.° and that
(fun f x => t~0 ) E p(f); the first follows from (3.4) and the second is an immediate
consequence of (C, P) F• (fun f x => t 0°) (for some R) that again follows from
~ f f
(3.4). •
We show an analogue of Proposition 3.13 for the syntax directed analysis:
Proposition 3.19
{(C, p) E C~e* X EnV* 1(C, PJ Fs e*} is a Moore family.
This result has as immediate corollaries that:

3.4 Constraint Based 0-CFA Analysis 173
• each expression e* has a Control Flow Analysis that is "less than"

T
(C*, p* ), and
~T
• each expression e* has a "least" Control Flow Analysis that is "less

than" (CI, pi).
This means that the properties obtained for the analysis of Table 3.1 in
Subsection 3.2.3 also hold for the analysis of Table 3.5 with the additional
restriction on the range of the analysis functions. In particular, any analysis
result that is acceptable with respect to Table 3.5 (and properly restricted to
c;clle* x ~ *) is also an acceptable analysis result with respect to Table
3.1. The converse relationship is studied in Exercise 3.11 and Mini Project
3.1.
Proof We shall write (CI' p""[) also for the greatest element of c-;clie* X ~*•
It is immediate to show that
(a) (C""[,PJH=s e
(b) if (C1, Pt) F• e and (C2, IJ2) F• e then ((Ct, {Jt) n (C2, {J2)) F• e.
for ali subexpressions e of e* by means of structural induction on e. This establishes

(a) and (b) also for e = e*. Next consider some
and note than one can write Y = {(C;, p;) 1i E {1, · · ·, n}} for some n ~O since
c-;clie* X ~ * is finite. That
then follows from (a) and (b) because nY = (C7:, {J7:) n (C1, {Jt) n ... n (Cn, Pn)· •
3.4 Constraint Based 0-CFA Analysis

Vf...e are now ready to consider efficient ways of finding the least solution
(C, p) such that (C, p) Fs e*. To do so we first construct a finite set C*[e*]
of constraints and conditionat constraints of the form
lhs ~ rhs (3.6)

{t} ~ rhs'::::} lhs ~ rhs (3.7)
where rhs is of the form C(l) or r( x), and lhs is of the form C(l), r( x), or {t},
and all occurrences of t are of the form fn x => ea or fun f x => ea. To
simplify the technical development we shall read (3.7) as
({t} ~ rhs' ::::} lhs) ~ rhs

and we shall write ls for lhs as well as {t} ~ rhs' ::::} lhs.
[con] C*[ct] = 0
[var] C*[x1] = {r(x) ~ C(f)}
[fn] C*[(fn x => eo)t] = {{fn x => eo} ~ C(f)}

U C*[eo]
[!un] C*[(fun f x => eo)t] = {{fun f x => eo} ~ C(f)}

U C*[eo] U {{fun f x => eo} ~ r(f)}
[app] C*[(ti1 t~2 l] = C*[ti 1 ] UC*[t~2 ]

U {{t} ~ C(fl):::} C(f2) ~ r(x)
1 t = (fn x => t~0 ) E Term*}
U {{t} ~ C(f1):::} C(fo) ~ C(f)

1 t = (fn x => t~0 ) E Term*}
U {{t} ~ C(f1):::} C(f2) ~ r(x)

1 t = (fun f x => t~0 ) E Term*}
U {{t} ~ C(fl):::} C(fo) ~ C(f)
1 t = (fun f x => t~0 ) E Term*}
(i.IJ C*[(if t~0 then ti1 else t~2 )t] = C*[t~0 ] U C*[tÎ 1 ] U C*[t~2 ]
u {C(fl) ~ C(f)}
U{C(f2) ~ C(f)}
(let] C*[(let x = ti 1 in t~2 )t] = C*[ti1 ] UC*[t~2 ]

U {C(il) ~ r(x)} U {C(i2) ~ C(f)}
[op] C*[(ti 1 opt~2 )t] =C*[tÎ 1 ]UC*[t~2 ]
Table 3.6: Constraint based Control Flow Analysis.
Informally, the constraints are obtained by expanding the clauses defining

(C, p) Fs e* into a finite set of constraints of the above form and then letting
C*[e*] be the set of individual conjuncts. One caveat is that all occurrences
of "C" are changed into "C" and that all occurrences of "jl' are changed into
"r" to avoid confusion: C(f) will bea set ofterms whereas C(f) is pure syntax
and similarly for p(x) and r(x).
Formally, the constraint based 0-CFA analysis is defined by the function C*
of Table 3.6: it makes use of the set Term* of subterms occurring in the
expression e* in order to generate only a finite number of constraints in the
clause for application; this is justified by Propositions 3.18 and 3.19.
If the size of the expression e* is n then it might seem that there could be
O(n2 ) constraints of the form (3.6) and O(n4 ) constraints of the form (3.7).
However, inspection of the definition of C* ensures that at most O(n) con-

straints of the form (3.6) and O(n 2 ) constraints of the form (3.7) are ever
generated: each of the O(n) constituents only generate 0(1) constraints of
the form (3.6) and O(n) constraints of the form (3.7).
Exarnple 3.20 Consider the expression
of Example 3.7. We generate the following set of constraints
C*[((fn x => x 1)2 (fn y => y3)4)5] =

{ {fn x => x 1 } ~ C(2),
r(x) ~ C(l),
{fn y => y3 } ~ C(4),
r(y) ~ C(3),
{fn x => x1 } ~ C(2)::::} C(4) ~ r(x),
{fn x => x 1 } ~ C(2)::::} C(l) ~ C(5),
{fn y => y3} ~ C(2)::::} C(4) ~ r(y),
{fn y => y 3 } ~ C(2) ::::} C(3) ~ C(5) }
where we use that fn x => x1 and fn y => y 3 are the only abstractions in
1Cerna*. •
3.4.1 Preservation of Solutions
It is important to stress that while (C,p) Fs e* is a logical formula, C*[e*] is

a set of syntactic entities. To give meaning to the syntax we first translate
the "(" and "r" symbols into the sets "C" and "p":
(c, {J)[C(i:)] c(e)

(C, p)[r(x)] p(x)
To deal with the possible forms of ls we additionally take:
(C, -p)[{t}] {t}
(C, p) [{t} ~ rhs' ::::} lhs] { ~(, p)[lhs] if {t} ~ (C,p)[rhs']

otherwise
Next we define a satisfaction relation (C, p) Fc (ls ~ rhs) on the individual

constraints:
(C, PJ Fc (ls ~ rhs) iff (C, p) [ ls] ~ (C, p) [ rhs]

This definition can be lifted to a set C of constraints by:
(C,P) Fc C iff V(ls ~ rhs) E C: (C,p) Fc (ls ~ rhs)

We then have the following result showing that all solutions to the set C*[e*]
of constraints also satisfy the syntax directed specification of the Control
Flow Analysis and vice versa:
Proposition 3.21
~ ~T T
If (C, P) ~ (C*, p*) then
(C, P) Fs e* if and only if (C, P) Fc C*[e*]
Thus the least solution (C, p) to (C, P) Fs e* equals the least solution to
(C, p) Fc C*[e*].
Proof A simple structural induction on e shows that
for all subexpressions e of e*; in the case of the function application (ti 1 t~2 )' the
assumption (C, {i) !;;;; (C~, p~) is used to ensure that C(f1) ~ Term*. •
3.4.2 Solving the Constraints

We shall present two approaches to solving the set of constraints C* [ e*]. First
we shall show that finding the least solution to C*[e*] is equivalent to finding
the least fixed point of a certain function; straightforward techniques allow
us to compute the least fixed point in time O(n 5 ) when the size of the ex-
pression e* is n. lmprovements upon this are possible, but to obtain the best
known result we shall consider a graph representation of the problem; this
will give us a O(n3 ) algorithm. This is indeed a common phenomenon in
program analysis: syntax directed specifications are appropriate for correct-
ness considerations but often they need to be "massaged" in order to obtain
efficient implementations.
Fixed point formulation. To show that finding the solution of the

set C* [ e*] of constraints is a fixed point problem we shall define a function
and show that it has a least fixed point lfp( F*) that is indeed the least solution
whose existence is guaranteed by Propositions 3.18 and 3.21.
We define the function F* by

FiC,p) = (Fl(C,P),F2(C,P))
where:
F1(C,p)(f) = U{(C,P)[ls] 1 (ls ~ C(f)) E C*[e*]}
H(C,p)(x) = U{(C,P)[ls] 1 (ls~ r(x)) EC*[e*]}
To see that this defines a monotone function it suffices to consider a constraint
lhs' ~ rhs' =? lhs ~ rhs
in C*[e*] and to observe that lhs' is of the form {t}; this ensures that
(C1,p1) ~ (C2,p2) implies Fi(C1,pl) ~ Fi(C2,p2) (for i = 1,2) because if
{t} ~ (Cl,Pl)[rhs'] then also {t} ~ (C2,P2)[rhs']. Since c;clie* X :En.V* is
a complete lattice this means that F* has a least fixed point and it turns out
also tobe the least solution to the set C*[e*] of constraints:
Proposition 3.22
Ifp(F*) =n{(C,P) 1 (C,ţ;) f=cC*[e*]}
Proof It is easy to verify that:

F*(C,ji) ~ (C,ji) iff (C,ji) Fc C*[e*]
Using the formula lfp(f) = n{x 1 f(x) ~ x} (see Appendix A) the result then
follows. •
If the size of e* is n then an element (C, P) of c;clie* x :En.V* may be viewed
as an O(n)-tuple of values from VaL. Since Vai* is a lattice of height O(n)
this means that C~e* x Vai* has height O(n2 ) and hence the formula
may be used to compute the least fixed point in at most O(n2 ) iterations.
A naive approach will need to consider all O(n 2 ) constraints to determine
the value of each of the O( n) components of the new iterant; this yields an
overall O(n5 ) bound on the cost.
Graph formulation. An alternative method for computing the least

solution to the set C*[e*] of constraints is to use a graph formulation of
the constraints. The graph will have nodes C(f) and r(x) for f E Lab* and
x E Var*. Associated with each node p we have a data field D[p] that initially
is given by:
D[p] = {t 1 ({t} ~ p) E C*[e*]}
The graph will have edges for a subset of the constraints in C*[e*]; each edge
will be decorated with the constraint that gives rise to it:
INPUT: C*[e*]
OUTPUT: (C, p)
W:= nil;
for q in Nodes do D[q] := 0;
for q in Nodes do E[q] := nil;
Step 2: Building the graph

for ce in C*[e*] do
case ce of
{t} s;;; p: add(p,{t});
P1 s;;; P2: E[p1] := cons(cc,E[p 1]);
{t} s;;; p =* Pl s;;; P2:
E[p1] := cons(cc,E[pl]);
E[p] := cons(cc,E[p]);
Step 3: Iteration
while W =1 nil do
q := head(W); W := taii(W);
for ce in E[q] do
case ce of
P1 s;;; P2: add(p2, D[pl]);
{t} s;;; P =* Pl s;;; P2:
if t E D[p] then add(p2, D[p!]);
Step 4: Recording the solution

for C in Lab* do C(C) := D[C(C)];
for x in Var* do p(x) := D[r(x)];
USING: procedure add(q,d) is
if • (d s;;; D[q])
then D[q] := D[q] U d;
W := cons(q,W);
Table 3. 7: Algorithm for solving constraints.
• a constraint Pl s;;; P2 gives rise to an edge from Pl to P2, and
• a constraint {t} s;;; p ==? P1 s;;; P2 gives rise to an edge from P1 to P2 and
an edge from p to P2.
Having constructed the graph we now traverse all edges in order to propagate
information from one data field to another. We make certain only to traverse
p D[p) E[p)
C(l) 0 [idx ~ C(2) =? C(l) ~ C(5)]
C(2) idx [idy ~ C(2) =? C(3) ~ C(5), idy ~ C(2) =? C(4) ~ r(y),
idx ~ C(2) =? C(l) ~ C(5), idx ~ C(2) =? C(4) ~ r(x)]
C(3) 0 [idy ~ C(2) =? C(3) ~ C(5)]
C(4) idy [idy ~ C(2) =? C(4) ~ r(y), idx ~ C(2) =? C(4) ~ r(x)]
C(5) 0 [l
r(x) 0 [r(x) ~ C(l))
r(y) 0 [r(y) ~ C(3)]
Figure 3.4: Ir:ţitialisation of data structures for example program.
an edge from Pl to P2 when D[p1] is extended with a term not previously

there (and this incorporates the situation where D[p1] is initially set to a
non-empty set). Furthermore, an edge decorated with {t} ~ p =? P1 ~ P2 is
only traversed if in fact tE D[p].
Tobe more specific consider the algorithm of Table 3.7. It takes as input a
s~*[e*] of constraints and produces as output a solution (C, {i)
E C~e* x
Env *. It operates on the following main data structures:
• a worklist W, i.e. a list of nodes whose outgoing edges should be tra-

versed;
• a data array D that for each node gives an element of Val*; and -
• an edge array E that for each node gives a list of constraints from which
a list of the successor nodes can be computed.
The set Nodes consists of C(f) for all fin Lab* and r(x) for all x in Var*.
The first step of the algorithm is to initialise the data structures. The second
step is to build the graph and to perform the initial assignments to the data
fields. This is established using the procedure add(q,d) that incorporates d
into D[q] and adds q to the worklist if d was not part of D[q]. The third step
is to continue propagating contributions along edges as long as the worklist
is non-empty. The fourth and final step is to record the solution in a more
familiar form.
Example 3.23 Let us consider how the algorithm operates on the ex-
pression ((fn x => x 1 ) 2 (fn y => y3 ) 4 ) 5 ofExample 3.20. After step 2 the
data structure W has been initialised to
w= [C(4), C(2)],
w [C(4),C(2)] [r(x),C(2)] [C(l),C(2)] [C(5),C(2)] [C(2)] [l

p D[p] D[p] D[p] D[p] D[p] D[p]
C(l) 0 0 idy idy idy idy

C(2) idx idx idx idx idx idx
C(3) 0 0 0 0 0 0
C(4) idy idy idy idy idy idy
C(5) 0 0 0 idy idy idy
r(x) 0 idy idy idy idy idy
r(y) 0 0 0 0 0 0
Figure 3.5: Iteration steps of example program.
and the data structures D and E have been initialised as in Figure 3.4 where
we have written idx for {fn x => x 1 } and idy for { fn y => y 3 }. The algo-
rithm will now iterate through the worklist and update the data structures W
and D as described by step 3. The various intermediate stages are recorded
in Figure 3.5. The algorithm computes the solution in the last column and
this agrees with the solution presented in Example 3.5. •
The following result shows that the algorithm of Table 3. 7 does indeed corn-
pute the solution we want:
Proposition 3.24
Given input C*[e*] the algorithm of Table 3.7 terminates and the
result (C, p) produced by the algorithm satisfies
and hence it is the least solution to C*[e*].
Proof It is immediate that steps 1, 2 and 4 terminate, and this leaves us with
step 3. It is immediate that the values of D[q] never decrease and that they can be
increased at most a finite number of times. It is also immediate that a node q is
added to the worklist only if some value of D[q] actually increased. For each node
placed on the worklist only a finite amount of calculation {bounded by the number
of outgoing edges) needs to be performed in order to remove the node from the
worklist. This guarantees termination.
Next let (C',p) bea solution to (C',p) Fc C*[e*]. It is possible to show that the
following invariant
VRE Lab*: D[C(R)] ~ C'(R)

Vx E Var*: D[r(x)] ~ p(x)
is maintained at all points after step 1. It follows that (C, {i) C (C', p) upon
completion of the algorithm.
We prove that (C, {i) Fc c* [e*] by contradiction. So suppose there exists ce E c* [e*]
such that (C, {i) Fc ce does not hold. If ce is {t} ~ p then step 2 ensures that {t} ~
D[p] and this is maintained throughout the algorithm; hence ce cannot have this
form. If ce is Pl ~ P2 it must be the case that the final value of D satisfies D[p1]
=f. 0 since otherwise (C, {i) Fc ce would hold; now consider the last time D[p1] was
modified and note that Pl was placed on the worklist at that time (by the procedure
add); since the final worklist is empty we must have considered the constraint ce
(which is in E[p1]) and updated D[p2] accordingly; hence ce cannot have this form.
If ce is {t} ~ p =} Pl ~ P2 it must be the case that the final value of D satisfies
D[p] =f. 0 as well as D[pl] =f. 0; now consider the last time one of D[p] and D[p1] was
modified and note that p or Pl was placed on the worklist at that time; since the
final worklist is empty we must have considered the constraint ce and updated D[p 2]
accordingly; hence ce cannot have this form. Thus (C,{i) Fc ce for all ce E C*[e*].
We have now shown that (C,{i) Fc C*[e*] and that (C,{i) [;;; (C',p) whenever
(C',p) Fc C*[e*]. It now follows that
(c, P'J = 1-1 {(c', P') (c', P') F=c c* [e*]}
1
as required. •
The proof showing that the algorithm terminates can be refined to show that
it takes at most O(n 3 ) steps if the original expression e* has size n. To see
this recall that C[e*] contains at most O(n) constraints of the form {t} s;; p
or P1 s;; P2, and at most O(n 2 ) constraints of the form {t} <;;; p::::} p 1 <;;; p 2 .
We therefore know that the graph has at most O(n) nodes and O(n 2 ) edges
and that each data field can be enlarged at most O( n) times. Assuming
that the operations upon D[p] take unit time we can perform the following
calculations: step 1 takes time O(n), step 2 takes time O(n 2 ), and step 4
takes time O(n); step 3 traverses each of the O(n 2 ) edges at most O(n) times
and hence takes time O(n 3 ); it follows that the overall algorithm takes no
more than O(n 3 ) basic steps.
Combining the three phases. From Proposition 3.24 we get that

the pair (C, p) computed by the algorithm of Table 3. 7 is the least solution
to C[e*], so in particular (C,p) Fc C[e*]. Proposition 3.21 shows that a
solution to the constraints will also be an acceptable analysis result for the
syntax directed specification, hence (C, p) Fs e*. Proposition 3.18 shows that
a solution that only involves program fragments of e* and that is acceptable
for the syntax directed specification, also is acceptable for the abstract spec-
ification, and therefore (C, p) f= e*. Thus we have the following important
corollary:
Corollary 3.25 Assume that (C, p) is the solution to the constraints

C[e*] computed by the algorithm of Table 3.7; then (C,P) f= e*. •
It is not the case that any (C, P) satisfying (C, P) f= e* can be obtained using
the above approach- see Exercise 3.11 and Mini Project 3.1.
For many applications it is the ability to compute the least (C, p) satisfy-
ing (C, P) f= e* that is of primary interest, rather than the ability to check
(C, p) f= e* for a proposed guess (C, p). However, there are applications where
it is the ability to check (C, P) f= e* that is of primary concern. As an example
consider an open system e0 that utilises resources of an umpecified library
e*. Then analyses and optimisations of e0 must rely on (C, P) expressing
all properties of interest about the library e*, i.e. (C, P) f= e*. This ensures
that the unspecified library e* can be replaced by another library e:
as long
as (C, p) continues to express all properties of interest about the library e:,
e:.
i.e. (C, P) f=
3.5 Adding Data Flow Analysis

In Section 3.1 we indicated that our Control Flow Analysis could be extended
with D~ Flow Analysis components. Basically, this amounts to extending
the set Val to contain abstract values other than just abstractions. We shall
first see how this can be done when the data flow component is a powerset
and next we shall see how it can be generalised to complete lattices. We shall
present the two approaches as abstract specifications only (in the manner of
Section 3.1), leaving the syntax directed formulations to the exercises.
3.5.1 Abstract Values as Powersets

Abstract domains. There are several ways to extend the value domain
Vai so as to specify both Control Flow Analysis and Data Flow Analysis.
A particularly simple approach is to use a set Data of abstract data values
(i.e. abstract properties ofbooleans and integers) since this allows us to define:
vE Vaid = P(Term U Data) abstract values
For each constant c E Const we need an element de E Data specifying the
abstract property of c. Similarly, for each operator op E Op we need a total
function
op : Vald XVald ---t Vald
telling how op operates on abstract properties. Typically, op will have a
definition of the form
VI Op V2 = u{dop(dl,d2) 1 dl EVi. nData,d2 E V2 nData}
3.5 Adding Data Flow Analysis 183
for some function dop : Data x Data -+ P(Data) specifying how the
operator computes with the abstract properties of integers and booleans.
Example 3.26 For a Detection of Signs Analysis we take Datasign = {tt,

ff, -, O, +} where tt and ff stand for the two truth values and -, O, and + for
the negative numbers, the number O, and the positive numbers, respectively.
It is then natural to define dtrue = tt and d7 = + and similarly for the other
+
constants. Taking as an example, we can base its definition on the following
table
d+ tt ff - o +
tt 0 0 0 0 0
ff 0 0 0 0 0
- 0 0 {-} {-} {-,o,+}
o 0 0 {-} {O} {+}
+ 0 0 {-,o,+} {+} {+}
and similarly for the other operators. •
Acceptability relation. The acceptability relation of the combined
analysis has the form
and is presented in Table 3.8. Compared with the analysis of Table 3.1 the
clause [con] now records that de is a possible value of c and the clause [op]
makes use of the function op described above. In the case of [i.IJ we have
made sure only to analyse those branches of the conditiona! that the analysis
of the condition indicates the need for; hence we can be more precise than
in the pure Control Flow Analysis - the Data Flow Analysis component of
the analysis can influence the outcome of the Control Flow Analysis. In
the manner of Exercise 3.3 similar improvements can be made to many of
the clauses (see Exercise 3.14) and thereby the specification becomes more
flow-sensitive.
Example 3.27 Consider the expression:
(let f = (fn x => (if (x 1 > 02 ) 3 then (fn y => y 4 ) 5

else (fn z => 25 6 ) 7 ) 8 ) 9
in ((f1o 3 11)12 013)14)15
A pure 0-CFA analysis will not be able to discover that the else-branch of
the conditiona! will never be executed so it will conclude that the subterm
with labei 12 may evaluate to fn y => y4 as well as fn z => 25 6 as shown
in the first column of Figure 3.6. The second column of Figure 3.6 shows that
when we combine the analysis with a Detection of Signs Analysis (outlined
[con] (C,P) Fd cf iff {de}~ C(i!)

[var] (C,P) Fd xe iff p(x) ~ C(f)
[Jn] (C,P) Fd (fn x => eo)e iff {fn x => eo} ~ C(f)
[!un] (C, P) Fd (fun f x => eo)e iff {fun f x => eo} ~ C(f)
[appJ (C,P) Fd (til t~2)e

iff (c, p) F=d til 1\ (C, p) F=d t~2 1\
('v'(fn X=> t~0 ) E C(l!):
(C, P) F=d t~o 1\
C(t2) ~ p(x) 1\ C(to) ~ c(t)) 1\
('v'(fun f x => t~0 ) E C(f!):
(C, P) F=d t~o 1\
C(t2) ~ p(x) 1\ c(to) ~ c(t) A
{fun f x => t~0 } ~ P(f))
[i.fl (C, P) Fd (if t~0 then tf1 el se t~2 )l

iff (c, P) F=d t~o 1\
(dtrue E C(lo) =? ((C,p) Fd tf 1 1\ C(l!) ~ C(l))) 1\
(dfalse E C(fo) =? ((C, P) Fd t~2 1\ C(f2) ~ C(f)))
[let] (C, P) Fd (let x = tf1 in t~2 )l

iff (c, P) F=d til 1\ (c, P) F=d t~2 A
c(t!) ~ p(x) 1\ C(t2) ~ c(t)
[op] (C, P) Fd (ti1 op t~2 )e

iff (c, P) F=d til 1\ (C, P) Fd t~2 1\
c(t!) 6P C(t2) ~ c(t)
Table 3.8: Abstract values as powersets.
in Example 3.26) then the analysis can determine that only fn y => y4 is
a possible abstraction at labei 12. Note that the Detection of Signs Analy-
sis (correctly) determines that the expression will evaluate to a value with
property {O}. •
The proof techniques introduced in Section 3.2 should suffice for proving the
correctness of the analysis with respect to the operational semantics. A slight
extension ofthe algorithmic techniques presented in Sections 3.3 and 3.4 (and
in Mini Project 3.1) suffices for obtaining an implementation of the analysis
provided that the set Data is finite.
Section 3.1 Subsection 3.5.1 1 Subsection 3.5.2

1 1
(C,fi) (C,fi) (c, fi) (0,8)

1 0 {+} 0 {+}
2 0 {O} 0 {O}
3 0 {tt} 0 {tt}
4 0 {o} 0 {O}
5 {fn y => y4} {fn y => y4} {fn y => y4} 0
6 0 0 0 0
7 {fn z => 25 6 } 0 0 0
8 {fn y => y\ {fn y => y4} {fn y => y4} 0
fn z => 25 6 }
9 {fn x => (-. ·)8} {fn x => (.. ·) 8} {fn x => (" ·)8} 0
10 {fn x => (.. ·) 8} {fn x => (· · ·) 8} {fn x => (.. ·)8} 0
11 0 {+} 0 {+}
12 {fn y => y4, {fn y => y4} {fn y => y 4} 0
fn z => 25 6 }
13 0 {O} 0 {O}
14 0 {o} 0 {O}
15 0 {o} 0 {O}
f {fn x => (o o o)8} {fn x => (· · ·) 8} {fn x => (.. ·)8} 0
X 0 {+} 0 {+}
y 0 {O} 0 {O}
z 0 0 0 0
Figure 3.6: Control Flow and Data Flow Analysis for example program.
Finally, we should stress that a solution to the analysis of Table 3.8 does
not immediately give a solution to the analysis of Table 3.1. More precisely,
(C,p) Fd e does not guarantee that (C',(J) f= e where 't:/C: C'(C) = C(C) n
Term and 't:/x : (J(x) = p(x) n Term. The reason is that the Control Flow
Analysis part of Table 3.8 is infiuenced by the Data Flow Analysis part in
the clause [i~: if for example the abstract value of the condition does not
include dtrue then the then-branch will not be analysed.
3.5.2 Abstract Values as Complete Lattices
Abstract domains. Clearly Vaid = P(TermUData) is isomorphic to

P(Term) x P(Data). This suggests that the abstract cache C: Lab--+ Vaid
could be split into a term component and a data component and similarly
for the abstract environment p: Var -+ Vaid.
Having decoupled 'P(Term) and 'P(Data) we can now consider replacing
'P(Data) by a more general coliection of properties. An obvious possibility
is to replace 'P(Data) by a complete lattice L and perform a development
closely related to that of the (forward) Monotone Frameworks of Chapter 2.
So let us define a monotone structure to consist of:
• a complete lattice L, and
• a set :F of monotone functions of L x L-+ L.
An instance of a monotone structure then consists of the structure (L, :F)

and
• a mapping t. from the constants c E Const to values in L, and
• a mapping f. from the binary operators op E Op to functions of :F.
Compared with the instances of the Monotone Frameworks of Section 2.3 we

omit the flow component since it will be the responsibility of the Control
Flow Analysis to determine this. The component t has been replaced by the
mapping t. giving the extremal value for ali the constants and the component
f. mapping labels to transfer functions has been replaced by a mapping of
the binary operators to their interpretation.
Example 3.28 A monotone structure corresponding to the development

of Subsection 3.5.1 will have L to be 'P(Data) and :F to be the monotone
functions of 'P(Data) x 'P(Data)-+ 'P(Data).
An instance of the monotone structure is then obtained by taking
for ali constants c (and with de E Data as above) and
for ali binary operators op (and where dop :Data x Data-+ 'P(Data) is as
above). •
Example 3.29 A monotone structure for Constant Propagation Analysis

will have L to be zi x P( {tt, ff}) and :F to be the monotone functions of
L x L-+ L.
An instance of the monotone structure is obtained by taking e.g. t 7 = (7, 0)

and Ltrue = (1_, { tt}). For a binary operator such as + we can take:
(z1 + z2, 0) if h = (zv · ·), l2 = (z2, · · ·),

and Z1,Z2 E Z
(1_,0) ifh=(z1,···),l2=(z2,···),
and z1 = l_ or z2 = l_
(T, 0) otherwise
•
We can now define the following abstract domains
v E Val
- P(Termj__ abstract values
p
C
E
E
Env
C;clie
=
-
Var-----+ Val abstract environments
Lab-----+ Val abstract caches
to take care of the Control Flow Analysis and furthermore

-
-
~
d Data
E L abstract data values
8 E DEnv
D E DCache - -
Var -----+ Data abstract data environments
Lab -----+ Data abstract data caches
to take care of the Data Flow Analysis.
Acceptability relation. The acceptability relation now has the form

(C,D,p,8)f=ve
and it is defined by the clauses of Table 3.9. In the clause [con] we see that the
t. component of the instance is used to restrict the value of the Bcomponent
of the analysis and in the clause [op] we see how the f. component is used. The
clause [i.fl has explicit tests for the two branches as in the previous approach
thereby allowing the Control Flow Analysis to benefit from results obtained
by the Data Flow Analysis component. As in the previous subsection, similar
improvements can be made to many of the other clauses so as to produce a
more flow-sensitive analysis.
Example 3.30 Returning to the expression of Example 3.27 and the De-
tection of Signs Analysis we now get the analysis result of the last column of
Figure 3.6. So we see that the result is as before. •
The proof techniques introduced in Section 3.2 should suffice for proving the
correctness of the analysis with respect to the operational semantics. A slight
extension ofthe algorithmic techniques presented in Sections 3.3 and 3.4 (and
in Mini Project 3.1) suffices for obtaining an implementation of the analysis
provided that L satisfies the Ascending Chain Condition (as is the case for
Monotone Frameworks).
[con] (C, 5,p,J) FD c'- iff Le!::;;; 5(i)

[var] (C, 5, p, 8) FD x'- iff p(x) ~ C(i) A 8(x) !::; ; 5(i)
[fn] (C, 5,p,8) FD (fn x => ea)f iff {fn x => eo} ~ C(i)
[!un] (C, 5, p, 8) FD (fun f x =>ea)~' iff {fun f x => eo} ~ C(i)

i'
[app] (C, D, p, 8) FD (tllf t2f
~ ~ ~
2)
iff (C,
--
D, p, -8) FD tll
l
A (C,
--
D, p, -8) FD t2f 2 A
(\i(fn => t~0 ) E C(i1) :
X
i'
(C, D, p, 8) FD t 0° A
~ ~ ~
C(i2) ~ p(x) A 5(i2)!::;;; 8(x) A

C(io) ~ C(i) A 5(i0 )!::;;; 5(i)) A
(\i(fun f X => t~0 ) E C(i!) :
--
(C, D, p, -8) FD t 0f ° A
C(i2) ~ p(x) A 5(i2) !::; ; 8(x) A
C(io) ~ C(i) A 5(io) !::; ; 5(i) A
{fun f X=> t~0 } ~ p(f))
[i.fJ (C, 5, p}) FD (if t~0 then 1 else t~2 )ftf

iff (C, D,p,8) FD t 0° A
-- ........ p_
(ttrue !::; ; D(io) =? (C, D, p, 8) FD t11 A

- -........ - l
C(il) ~ C(i)A
5(i!)!::;;; 5(i)) A
f
(tfalse!::;;; D(io) =? (C,D,p,8) FD t22 A
~ ~ ~ ~
C(i2) ~ C(i)A
6(t2)!::;;; 5(t))
[let] (C, 5, p, 8) f= D (let x = tf 1 in t~2 )f
iff (C,D,p,8) FD tll
-- f_ -
A (C,D,p,8)
-- -
FD t2f_ 2 A
C(i1) ~ P(x) A 5(i!)!::;;; 8(x) A
C(i2) ~ C(i) A 5(i2) !::; ; 5(i)
[op]
Table 3.9: Abstract values as complete lattices.

3.6 Adding Context lnformation 189
Staging the specification. Let us briefiy consider the following al-

ternative clause for [i.fl where the data fiow component cannot infiuence the
control fiow component because we always make sure that the analysis result
is acceptable for both branches:
(C, 6, p, 8) ti
1=~ (if t~0 then 1 else 2 ) ' tg
iff (C, D, p, 8) 1=~ t~0 A
ti
(C, 6, p, 8) 1=~ 1 A C(fl) <;;;; C(f) A D(f1) ~ D(f) A
tg
(C, 6, p, 8) 1=~ 2 A C(f2) <;;;; C(f) A D(f2) ~ D(f)
Unlike what was the case for the analyses of Tables 3.8 and 3.9, a solution to
the analysis modified in this way does give rise to a solution to the analysis
of Table 3.1; to be precise (C, 6, P, 8) 1=~ e guarantees (C, p) 1= e.
In terms of implementation this modification means that the constraints for
the control fiow component (C and p) can be solved first, and based on this
the constraints for the data fiow component (D and 8) can be solved next. If
both sets of constraints are solved for their least solution this will stiH yield
the least solution of the combined set of constraints.
Example 3.31 Let us return to Example 3.30. If we modify the clause

for [i.fl as discussed above then the resulting analysis will have Cand p as in
the column for the pure analysis from Section 3.1 and 6 and 8 will associate
slightly larger sets with some of the labels and variables:
0(6) = {+}
0(14) {0,+}
0(15) {0, +}
8(z) {o}
This analysis is less precise than those of Tables 3.8 and 3.9: it will only
determine that the expression will evaluate to a value with the property
{0,+}. •
Imperative constructs and data structures. Mini Project 3.2

shows one way of extending the development to track creation points of data
structures. Mini Project 3.4 shows how to deal with imperative constructs
in the manner of the imperative language WHILE of Chapter 2.
3.6 Adding Context Information

The Control Flow Analyses presented so far are imprecise in that they cannot
distinguish the various instances of function calls from one another. In the
terminology of Section 2.5 the 0-CFA analysis is context-insensitive and in

the terminology of Control Flow Analysis it is monovariant.
Example 3.32 Consider the expression:
(let f = (fn x => x1)2

in ((f3 f4)5 (fn y => y6)7)B)9
The least 0-CFA analysis is given by (C;d, p;d):
c;d(l) {fn x => x 1 ,fn y => y6}

c;d(2) {fn x => x 1 }
c;d(3) = {fn x => x 1 }
c;d(4) {fn x => x 1 }
C;d(5) {fn x => x 1 ,fn y => y6}
c;d(6) {fn y => y6}
cid(7) {fn y => y6}
c;d(s) {fn x => x 1 ,fn y => y6}
c;d(9) {fn x => x 1 ,fn y => y6}
Pid(f) {fn x => x 1 }

Pid(x) {fn x => x1 ,fn y => y6}
Pid(y) {fn y => y6}
So we see that x can be bound to fn x => x 1 as well as fn y => y6 and

hence the overall expression (labei 9) may evaluate to either of these two
abstractions. However, it is easy to see that in fact only fn y => y6 is a
possible result. •
To get a more precise analysis it is useful to introduce a mechanism that

distinguishes different dynamic instances of variables and labels from one
another. This results in a context-sensitive analysis and in the terminology
of Control Flow Analysis the term polyvariant is used. There are several
approaches to how this can be done. One simple possibility is to expand the
program such that the problem does not arise.
Example 3.33 For the expression of Example 3.32 we could for example
consider
let fl = (fn xl => xl)

in let f2 = (fn x2 => x2)
in (fl f2) (fn y => y)
3.6 Adding Context Information 191
and then analyse the expanded expression: the 0-CFA analysis is now able
to deduce that x1 can only be bound to fn x2 => x2 and that x2 can only
be bound to fn y => y so the overall expression will evaluate to fn y => y
only. •
A more satisfactory solution to the problem is to extend the analysis with

context information allowing it to distinguish between the various instances
of variables and program points and stiH analyse the original expression.
Examples of such analyses include k-CFA analyses, uniform k-CFA analyses,
polynomial k-CFA analyses (mainly of interest for k >O) and the Cartesian
Product Algorithm.
3.6.1 Uniform k-CFA Analysis

Abstract domains. A key idea is to introduce context to distinguish
between the various dynamic instances of variables and program points.
There are many choices concerning how to model contexts and how they
can be modified in the course of the analysis. In a uniform k-CFA analy-
sis (as well as in a k-CFA analysis) a context J records the last k dynamic
call points; hence in this case contexts will be sequences of labels of length at
most k and they will be updated whenever a function application is analysed.
This is modelled by taking:
J E ~ = Lab::;k context information
Since the contexts will be used to distinguish between the various instances
of the variables we will need a context environment to determine the context
associated with the current instance of a variable:
ce E CEnv = Var ---+ ~ context environments
The context environment will play a role similar to the environment of the
semantics; in particular, this means that we shall extend the abstract values
to contain a context environment:
v E Val = P(Term x CEnv) abstract values

So in addition to recording the abstractions (fn x => e and fun f x => e)
we will also record the context environment at the definition point for the
free variables of the term. This should be compared with the Structural
Operational Semantics of Section 3.2 where the closures contain information
about the abstraction as well as the environment determining the values of
the free variables at the definition point.
The abstract environment p will now map a variable and a context to an
abstract value:
pE~ (Var x ~)---+Val abstract environments
[con] (C, p) f=6e ci always

[var] (C, p) f=6e xi iff p(x, ce(x)) <::;; C(f!, 8)
[In] (C,p) f=6e (fn x => eo)t iff {(fn x => eo,ceo)} <::;; C(f!,8)
where ceo = ce 1 FV(fn x => eo)
[!un] (C, p) f=6e (fun f x => eo)t iff { (fun f x => eo, ceo)} <::;; C(f, 8)
where ceo = ce 1 FV(fun f x => eo)
[app] (C, p) f=6e (t~l t~2 )i

iff (C, p) f=6e t~ 1 1\ (C, p) f=6e t~2 1\
(\i(fn x => t~0 ,ceo) E C(f1,8):
(c, P) F= ~:~ t~o 1\
C(f2, 8) <::;; P(x, 8o) 1\ C(fo, 8o) <::;; C(f!, 8)
where 8o = f8,fh
and cea = ceo [x t--+ 8o]) 1\
(\i(fun f x => t~0 , ceo) E C(f1, 8) :
(C, P) F~:~ t~0 1\
C(f2, 8) <::;; p(x, 8o) 1\ C(fo, 8o) <::;; C(f, 8) 1\
{(fun f x => t~0 , ceo)} <::;; p(f, 8o)
where 8o = f8,fh
and Cea = Ceo[f t--+ 8o, X t--+ 8o])
[if] (C, p) f=6e (if t~0 then t~ 1 el se t~2 )i

iff (C, p) f=6e t~0 1\ (C, P) f=8e t~ 1 1\(C, P) f=8e t~2 1\
c(t1, 8) <::;; c(t, 8) 1\ C(t2, 8) <::;; C(t, 8)
[let] (C, p) f=6e (let x = t~ 1 in t~2 )f

iff (C, p) f=6e tfl 1\ (C, P) f=6e' t~2 1\
c(t1, 8) <::;; P(x, 8) 1\ c(t2, 8) <::;; c(t, 8)
where ce' = ce[x t--t 8]
[ op] (C, p) f=6e (t~ 1 op t~2 )f iff (C, P) f=6e tf1 1\ (C, P) f=6e t~2
Table 3.10: Uniform k-CFA analysis.
Typically we will use a context environment to find the context associated

with the variable of interest and then use it together with the variable to
access the abstract environment. This means that indirectly we get the effect
of having local abstract environments in the abstract values although p is still
a global entity as in the previous sections.
The uniform k-CFA analysis differs from the k-CFA analysis in performing
a similar development for the abstract cache that now maps a labei and a
context to an abstract value:
C E Ciclle = (Lab X~) ---+Val abstract caches
Given information about the context of interest we can determine the abstract
value associated with a labei. Again we indirectly get the effect of having a
cache for each possible context although it is still a global entity. (In k-CFA
one has ciclle = (Lab X CEnv) ---+ Vai.)
Acceptability relation. The acceptability relation for uniform k-

CFA is presented in Table 3.10. It is defined by formulae of the form
where ce is the current context environment and 8 is the current context.

The formula expresses that (C, p) is an acceptable analysis of e in the context
specified by ce and 8. The clauses for the various constructs are very much
as those in Table 3.1 and will be explained below.
In the clause [var] we use the current context environment ce to determine the
context ce(x) of the current instance of the variable x and then the abstract
value of the variable is given by p(x, ce(x)). The current context is 8 so we
have to ensure that p(x, ce(x)) ~ C(.e, 8).
In the clause [fn] we record the current context environment as part of the
abstract value and (as in the Structural Operational Semantics of Table 3.2)
we restrict the context environment to the set of variables of interest for the
abstraction. The clause [fun] is similar.
In the clause [app] we analyse the two subexpressions using the same context
and context environment as the composite expression. When we find a po-
tential abstract value, say (fn x => t~0 , cea), that the operator may evaluate
to, it will contain a local context environment cea that was created at its
definition point. When analysing t~0 we will have passed through the appli-
cation point e, so the current context will be updated to include e and this
will also be the context associated with the variable x in the updated version
of the context environment cea used for the analysis of t~0 • The new context
is 18, fh which (as in Section 2.5) denotes the sequence [8, f] but possibly
truncated (by omitting elements on the left) so as have length at most k. In
the case where the operator has the form (fun f x => t~0 , cea) we proceed in
a similar way and note that f as well as x will be associated with the new
context in the analysis of the body of the function.
The clauses for [ifl, [let] and [op] are fairly straightforward modifications of
those of Table 3.1; however, note that the context ofthe bound variable ofthe
let-construct is the current context (as no application point is passed). We
shall dispense with proving the correctness of the analysis and with showing
how it can be implemented.
Example 3.34 We shall now specify a uniform 1-CFA analysis for the
expression of Example 3.33:
The initial context will be A, the empty sequence of labels. In the course
of the analysis the current context will be modified at the two application
points with labels 5 and 8; since we only records call strings of length at most
one the only contexts of interest will therefore be A, 5 and 8. There are four
context environments of interest:
ceo = [] the initial (empty) context environment,
ce1 = ceo[f f-+ A] the context environment for the analysis of the body
of the let-construct,
ce2 = ceo[x f-+ 5] the context environment used for the analysis of the
body of f initiated at the application point 5, and
ce3 = ceo[x f-+ 8] the context environment used for the analysis of the
body of f initiated at the application point 8.
Let us take c:d and IJ:d to be:
c:d(l, 5) = {(fn X => x\ceo)} c:d(1,8)={(fn y => y 6 ,ceo)}

c:d(2,A)={(fn X=> x1,ceo)} c:d(3, A) = {(fn => xl,ceo)}
X
c:d(4,A)={(fn X=> x 1 ,ceo)} crd(5, A)= {(fn X => xl,ceo)}

c:d(7,A) = {(fn y => y 6 ,ceo)} crd(8,A) = {(fn y => y 6 ,ceo)}
c:d (9, A) = {(fn y => y 6 ,ceo)}
Pfd(f,A)={(fn x => x\ceo)}

Pfd(x, 5) = {(fn x => x 1 ,ceo)}
We shall now show that this is an acceptable analysis result for the example
expression:
(c:d,Pfd) f=~o (let f = (fn x => x1)2 in ((f 3 f 4) 5 (fn y => y6)7)8)9
According to clause [let], it is sufficient to verify that
(crd, IJ:d) F~o (fn X => xl )2

(crd,IJ:d) F=~l ((f3 f4)5 (fn Y => y6f)s
because crd(2, A) ~ IJ:d(f, A) and crd(8, A) ~ crd(9, A). This is straightfor-

ward except for the last clause. Since c:d(5, A) = {(fn X => x1,ceo)} it is,
according to [app], sufficient to verify that
(c:d, Prd) F=~l (f3 f4)5

(c:d, P(d) F=~l (fn Y => y6)7
( (~ldl p~ld ) 18
~ce3 xl
because C(d(7, A)~ Pfd(x, 8) and C(d(l, 8) ~ C(d(8, A). This is straightforward
except for the first clause. Proceeding as above we see that C(d(3,A) = {(fn
x => x\ceo)} and it is sufficient to verify
because C(d(4, A)~ P(d(x, 5) and c:d(l, 5) ~ C(d(5, A). This is straightforward.
The importance of this example is that it shows that the uniform 1-CFA
analysis is strong enough to determine that fn y => y6 is the only result
possible for the overall expression unlike what was the case for the 0-CFA
analysis in Example 3.32. We can also see that, since P(d(y,8) = 0 for all
8 E {A, 5, 8} it follows that fn y => y6 is never called upon a function. •
The resulting analysis will have exponential worst case complexity even for
the case where k = 1. To see this assume that the expression has size n and
that it has p different variables. Then ~ has O( n) elements and hence there
will be O(p · n) different pairs (x, 8) and O(n 2 ) different pairs (f, 8). This
means that (C, p) can be seen as an O(n 2 ) tuple of values from Vai. Since
Vai itself is a powerset of pairs of the form (t, ce) and there are O(n · nP)
such pairs it follows that Val has height O(n · nP). Since p = O(n) we have
the exponential worst case complexity claimed above.
This should be contrasted with the 0-CFA analysis developed in the previous
sections. It corresponds to letting ~ be a singleton. Repeating the above
calculations we can see (C, fi) as an O(p+n) tuple ofvalues from Vai, and Vai
will be a lattice of height O(n). In total this gives us a polynomial analysis
as we already saw in Section 3.4.
The worst case complexity of the uniform k-CFA analysis (as well as the k-
CFA analysis) can be improved in different ways. One possibility is to reduce
the height of the lattice Vai using the techniques of Chapter 4. Another
possibility is to replace all context environments with contexts, i.e. to have
Vai = P(Term x ~); clearly this will give a lattice of polynomial height.
This idea is closely related to the so-called polynomial k-CFA analysis where
the analogues of context environments are forced to be constant functions,
i.e. to map all variables to the same context. In the case of polynomiall-CFA
the analysis is of complexity O(n 6 ).
Interprocedural analysis revisited. Let us compare the above

development with that of Section 2.5 where we considered interprocedural
analysis for a simple imperative procedure language.
Recall that the abstract domain of interest in Section 2.5 has the form
D..~L
where tl is the context information and L is the complete lattice of abstract

values of interest. For each labei f the analysis will determine two elements
A o ( f) and A. (f) of tl ~ L describing the situatian before and after the
elementary block labelled f is executed. So we have
A o, A. : Lab ~ (tl ~ L)
and in the terminology of the present chapter we may regard these functions
as abstract caches. There is no analogue of the abstract environment in
Section 2.5- the reason is that the procedure language is so simple that it is
not needed: the abstract environment records the context of the free variables
and since all free variables in the procedures are global variables there is no
need for this component.
We can now reformulate the above development as follows. We can take the
abstract domain of interest to be
tl ~ P(Term x CEnv)
and reformulate the abstract cache and the abstract environment as having
the functionalities:
C: Lab ~ tl ~ P(Term x CEnv)
p: Var~ tl ~ P(Term x CEnv)
Thus the abstract caches of the interprocedural analysis and the uniform k-
CFA analysis (using caii strings) have the same overall functionality and we
may conclude that the two analyses are variations over a theme.
3.6.2 The Cartesian Product Algorithm

The Cartesian Product Algorithm, abbreviated CPA, has been developed for
object-oriented languages but the main ideas can be expressed using a varia-
tion of our functionallanguage in which functions take m arguments (m > 0):
t ::= · · ·1 fn x1,· · ·,Xm => eb 1 eo(el, · · ·,em)
For notational simplicity we shall dispense with recursive functions through-

out this subsection. Tobe faithful to the official description of CPA we shall
furthermore impose the well-formedness condition that all function abstrac-
tions are closed, i.e. FV( fn x 1 , · · · , Xm => eb) = 0, much as was the case for
the procedurallanguage considered in Section 2.5. We leave a more general
treatment to Exercise 3.17.
Rephrasing the 0-CFA analysis. The first step is to adapt the

specification of the 0-CFA analysis to deal with functions taking m argu-
ments. Even though CPA is a very practica! oriented algorithm it will be
appropriate to consider the abstract specification in Table 3.1 (rather than
the syntax directed specification in Table 3.5). We modify it as follows:
~ l ~
(C,p) f= (fn X1, · · · ,xm => eb) iff {fn XI,··· ,Xm => eb} ~ C(f)
(c, P') F= (t~o (ti\···, t;; ))t

iff (c, P') F= t~o A (c, P') F= til A · · · A (c, P') F= t;; A
l ~
\f(fn XI,···, Xm => tbb) E C(fo) :
C(fi) X··· X C(fm) ~ p(x1) X··· X p(xm) 1\
(c, P') F= t!b A
c(tb) ~ c(t)
The third last conjunct in the clause for function application can be written
in the case where no C(fi) is empty.
The Cartesian Product Algorithm. We next extend the analysis

to take context into account. This will be in the form of the actual arguments
supplied to the function:
oE ~ = Termm = Term x · · · x Term (m times)
Recalling that Vai = P(Term) we then redefine the abstract domains as

follows:
p E Env (Var x ~) --+Vai
( E C;clie (Lab x ~)--+Val
The key clauses in the CPA analysis then are:
~ o l ~
(C, P) f=cPA x iff p(x, o) ~ C(f, o)
.-. ~ 8 R• -.
(C, p) FcPA (fn XI, ... ' Xm => eb) Iff {fn Xl, ... 'Xm => eb} ~ C(f, o)
(C, p) F~PA (t~o(til' ... 't;; )l

iff (C, P) F~PA t~o 1\ (C, P) F~PA ti 1 1\ · · · 1\ (C, P) F~PA t;; 1\
l ~
\f(fn X1, · · ·, Xm => tbb) E C(fo, O)
\fob E C(fl, o) X •.. X C(fm, o) :
{Ob} ~ p(xl) X • • • X p(xm) 1\
(C, P) F~bPA t!b 1\
c(tb, ob) ~ C(f, o)
It is clear from this specification that the body of the function is analysed sep-
arately for each possible tuple of arguments and that no merging of data takes
place. To be practica} we need to implement the analysis using memoisation
so that the bodies are only analysed once. This can be dane by organis-
ing each (C, P) l=~bPA t~b into so-called templates and to maintain them in a
global pool; when a template is created it is only added to the pool if it is
not already present.
The Cartesian Product Algorithm derives its name from the cartesian product
C(J:\, 8) x · · · x C(lm, 8) over which 8b ranges. The analysis can be implemented
in a straightforward lazy manner because the product grows monotonically:
C(C1, 8) x · · · x C(lm, 8) will increase each time one of the C(Ci, 8) increases
(assuming that none is empty). A mild generalisation is studied in Exercise
3.17.
Interprocedural analysis revisited. Let us once more compare

the development to Section 2.5 but this time to the development based on
assumption sets. The development in Section 2.5 is based on
Ao, A. : Lab-+ (~-+ L)
where ~ is the context information and L = P(D) is the powerset of interest,

and the current development can be reformulated as operating on
C: Lab -+ ~ -+ Vai
p: Var-+~-+ Vai
where Vai= P(Term) is the powerset of interest. Clearly D and Term can
be taken to be equal and the fact that ~ = Term then shows that ~ = D and
we may conclude that "small assumption sets" and the Cartesian Product
Algorithm are variations over a theme.
Concluding Remarks
Control Flow Analysis for functional languages. Many of
the key ideas for Control Flow Analysis have been developed within the
context of functionallanguages. The concept of k-CFA analysis seems due to
Shivers [156, 157, 158]; other works on 0-CFA-like analyses include [163, 136,
57, 56]. The ideas behind k-CFA and polynomial k-CFA analysis were further
clarified in [79] that also established the exponential complexity of k-CFA
analysis for k > O; it also related a form of Set Based Analysis [70] to 0-CFA.
The uniform k-CFA analyses were introduced in [122] as a simplification of
the k-CFA analyses; an obvious variation over this is to record the set of the
last k distinct call points (see Exercise 3.15). Yet another variation over the
same theme is Closure Analysis; an early and often neglected development

may be found in [152].
The formulation of the analyses (as well as the one presented in Table 3.1)
would often seem to be more appropriate for a dynamically scoped than for a
statically scoped language: The 0-CFA analysis coalesces information about
variables having several defining occurrences even if they differ in their scape;
clearly the analysis can easily be modified so that it more directly models
static scape (see Exercise 3.7) rather than relying on no variable having more
than one defining occurrence.
To the extent these developments go beyond 0-CFA they establish additional
context (called mementoes, tokens or contours) for representing information
concerning the dynamic call chain. The most common approach links back
to the use of call strings in Section 2.5. The Cartesian Product Algorithm
[2] was originally developed for object-oriented programs and amounts to the
use of "small assumption sets" in Section 2.5.
Another way to establish context is to represent the static call chain. This
seems first to be described by [80] as part of their so-called "polymorphic
splitting" analysis. A more general set-up was formulated in [122] that also
argued for the need to base abstract specifications on coinductive methods -
bearing in mind that coinductive and inductive methods may coincide as in
the case of syntax directed specifications.
Clearly Control Flow Analysis should be combined with Data Flow Analysis
to strengthen the quality of the control information as well as providing the
data f:low information of interest. Our treatment in Section 3.5 only presents
the first steps in this direction: a more ambitious approach is outlined in
Mini Project 3.4 which is based in [126]. In fact, some authors would claim
that the analysis presented in Section 3.1 should not be regarded as a 0-CFA
analysis since it does not include data f:low analysis (as in Section 3.5) and
does not take evaluation order into account (as in Exercises 3.3 and 3.14); in
our view these developments are all variations over a theme.
Most of the papers cited above directly formulate a syntax directed specifi-
cation, perhaps proving it semantically sound, and perhaps showing how to
generate constraints so as to obtain an efficient implementation. The use of
abstract specifications first appeared in [80, 122] and has the advantage of
being more directly applicable to open systems (that allow to interface with
the library routines provided by the environment) and also to the ideas of
Abstract Interpretation of Chapter 4. In particular, the notion of reachability
suggests itself rather naturally [21, 60], it becomes clearer how to integrate
ideas from Abstract Interpretation into Control Flow Analysis, and one does
not inadvertently restrict oneself to closed systems only. (The notion of
reachability is considered in Mini Project 3.1 which is based on [60].)
Only few papers [125] discuss the interplay between the choice of specification
style for the analysis and the choice of semantics. We have used a small-step
Structural Operational Semantics rather than a big-step semantics in order
to express the semantic correctness also of looping programs. We have used
an environment based semantics in order to ensure that we do not "modify"
the bodies of functions before they are called, so that function abstractions
can meaningfully be used in the value domains of our analysis (125]. As a
consequence we have had to introduce intermediate expressions (closures and
bindings) and have had to specify the abstract analysis also for intermediate
expressions; for the syntax directed specification and the constraint based
analysis this was not necessary given that semantic correctness had already
been dealt with. Alternative choices are clearly possible but are likely to
sacrifice at least some of the generality offered by the present approach.
Control Flow Analysis for other language paradigms. An-

other main application of Control Flow Analysis has been for object-oriented
languages: one simply tracks objects rather than functions [3, 124, 137]. As
a reminder of the close links between Data Flow Analysis and Control Flow
Analysis we should also mention that some approaches [178, 139] are closer to
the presentation of Chapter 2. A common theme among the more advanced
studies is the incorporation of context (related to k-CFA) and an abstract
store (133] (to deal with imperative aspects like method update). To increase
the precision, local versions of the abstract store need to exist at all program
points, and abstract reference counts are needed to incorporate a "kill" com-
ponent (in the manner of Chapter 2). We refer to the above literature for
further details of how to formulate such analyses and how to choose a proper
balance between precision and cost.
Control Flow Analysis for concurrent languages has received relatively little
attention [22]. However, variations ofthe techniques presented in this chapter
have been used to analyse functional languages extended with concurrency
primitives allowing processes to be created dynamically and to communicate
via shared locations or channels [78, 57, 60, 22, 23].
In this book we do not consider logic programming languages. However, we
should point out that Control Flow Analysis also has applications for logic
programming languages and that set based analysis was first developed for
this class of languages [72, 73].
Set-Constraint Based Analysis. Control Flow Analysis is just one

approach to program analysis where the use of constraints pays off. In this
chapter we have have taken the following approach: (i) first we have given
an abstract specification of when a proposed solution is acceptable, (ii) then
we have developed an algorithm for generating a set of constraints expressing
that a proposed solution is acceptable, and (iii) finally we have solved the
set of constraints for the least solution. For the solution of set constraints in
step (iii), it is unimportant how the constraints were in fact obtained. For
this reason, it is often said that set constraints allow the separation of the
specification of an analysis from its implementation and that set constraints
are able to deal with forward analyses as well as backward analyses and
indeed mixtures of these.
Set constraints [72, 7] have a long history [143, 84]. They allow us to express
general inclusions of the form
where set expressions, 8, set variables, V, and set constructors, C, may be

built as follows:
8 .. _ V 101 81 U 82 1 81 n 82 1 C(81, .. ·, 8n)

(81 ~ 82) =* 83 1 (81 :f: 0) =* 82 1 c-i(8) 1 -.S 1 .. ·
V .. - XIYI···
C .. _ true 1 false 1 O 1 · · · 1 cons 1 nill · · ·
Set constraints allow the consideration of constructors that are not just
nullary and this allows us to record also the shape of data structures, so
for example cons(81, 82) U nil expresses possibly empty lists whose heads
come from 8 1 and whose tails come from 82. The associated projection selects
those terms (if any) having the required shape, e.g. cons- 1(8) produces the
heads that may be present in 8. We have seen conditiona! constraints before
and it turns out that projection is so powerful that it can be used to code
conditiona! constraints. Finally, it is sometimes possible to explicitly take
the complement of a set but this adds to the complexity of the development.
(It means that solutions can no longer be guaranteed using Tarski's Theorem
and sometimes a version of Banach's Theorem may be used instead.)
The complexity of solving a system of set constraints depends rather dra-
matically on the set forming operations allowed and therefore many versions
have been considered in the literature. We refer to [6, 135] for an overview
of what is known in this area; here we just mention [28] for a general result
and [70, 10] for some cubic time fragments.
However, it is worth pointing out that many of these results are worst-case
results; benchmark results of Jaganathan and Wright [80] shows e.g. that in
practice a 1-CFA analysis may be faster than a 0-CFA analysis despite the
fact that the former has exponential worst-case complexity and the latter
polynomial worst-case complexity. The reason seems to be that the 0-CFA
analysis explores most of its polynomial sized state space whereas the 1-CFA
analysis is so precise that it only explores a fraction of its exponentially sized
state space.
The basic idea behind many of the solution procedures for set constraints is
roughly as follows [9]:
1. Dynamically expand conditiona! constraints, based on the condition

being fulfilled, until no more expansion is possible.
2. Remove all conditiona! constraints and combine the remaining con-
straints to obtain the least solution.
This is not quite the algorithm used in Section 3.4 where we were only in-
terested in solving a rather limited class of constraints for 0-CFA analysis.
When generating the constraints in Table 3.6 we were able to "guess a uni-
verse" Term* that was sufficiently large and this allowed us to generate
explicit versions of the conditiona! constraints; in fact a superset of all those
to be considered in step 1 of the above algorithm. Therefore our subsequent
constraint solving algorithm in Table 3. 7 merely needed to check the already
existing constraints and to determine whether or not they could contribute
to the solution. In practice, the above "lazy'' algorithm is likely to perform
much better than the "eager" algorithm of Tables 3.6 and 3.7.
Mini Projects
Mini Project 3.1 Reachability Analysis
The syntax directed analysis of Table 3.5 analyses each subexpression of e*

"exactly once" rather than "at most once" as really called for. In this mini
project we shall study one way to amend this.
The idea is to introduce an abstract reachability component
RE Reach = Lab ___, P( { on})
and to modify the syntax directed analysis to have a relation of the form
(C,p, R) F=~ e
The idea is that fn x => tgo has {on} ~ R(C 0 ) if and only if the function is
indeed applied somewhere, and that the "recursive call" (C, p, R) Fs tgo is
performed if and only if {on} ~ R( C0 ).
1. Modify Table 3.5 to incorporate this idea.
2. Show the following analogue of Proposition 3.18: If (C, p, R) f=~ t;*,

f
{on} ~ R(C*) and (C,p)!;;;; (C* ,p*) then (C,p) f= t**.
~ ~ ~ ~T ~T ~ ~
3. Determine whether or not the statements

if (C, p) f= e* then (C, p, R) f=~ e* for some R
T
if (C, P) f= e*
~ ~ ~T ~ ~ ~
and (C, p) ~ (C* , p*) then (C, p, R) f=~ e* for some R

hold in general. •
Mini Projects 203
Mini Project 3.2 Data Structures
The language considered so far only includes simple data like integers and
booleans. In this mini project we shall extend the language with more general
data structures:
Here C E Constr denotes an n-ary data constructor. A data element is

constructed by C (e1, · · · , en): it has tag C and its components are the values
of e1, · · ·, en. The case construct will first determine the value vo of eo, if
vo has the tag C then X1, · · · , Xn will be bound to the components of Vo and
e1 is evaluated. If vo does not have tag C then x is bound to Vo and e2 is
evaluated.
As an example we may have Constr = { cons, nil} so we have the following
expression (omitting labels) for reversing a list:
let append = fun app xs => fn ys =>

case xs of cons(z,zs) => cons(z,app zs ys)
or xs => ys
in fun rev xs => case xs of cons(y,ys) =>
append (rev ys) (cons(y,nil()))
or xs => nil()
To specify a 0-CFA analysis for this language we shall take
Vai= P(TermU {C(fv · · ,fn) 1 CE Constr,f1, · · · ,fn E Lab})
As before the terms of interest are fn x => eo and fun f x => eo for recording
the abstractions. The new contribution is a number of elements of the form
C(f1, · · ·, fn) denoting a data element C(v1, · · ·, vn) whose i'th component
might have been created by the expression at program point fi.
1. Developa syntax directed analogue of the analysis in Table 3.5.
2. Modify the constraint generation algorithm of Table 3.6 to handle the

new constructs and make the necessary changes to the constraint solv-
ing algorithm of Table 3.7.
For the more ambitious: are there any difliculties in developing an abstract
analogue of the analysis in Table 3.1? •
Mini Project 3.3 A Prototype lmplementation
In this mini project we shall implement the pure 0-CFA analysis considered
in Section 3.3. As implementation language we shall choose a functional
language such as Standard ML or Haskell. We can then define a suitable
data type for FUN expressions as follows:
type var string

type label int
datatype const = Num of int 1 True 1 False
datatype exp Labei of term * label
and term Const of const 1 Var of var
Fn of var * exp 1 Fun of var * var * exp
App of exp * exp 1 lf of exp * exp * exp
Let of var * exp * exp 1 Op of string * exp * exp
1. lmplement the constraint based control flow analysis of Section 3.4; this
includes defining an appropriate data structure constraints for (condi-
tiona!) constraints.
2. Implement the graph based algorithm of Section 3.4 for solving con-
straints; this involves choosing appropriate data structures for the work-
list and the two arrays used by the algorithm.
For the more ambitious: generalise your program to perform some of the more
advanced analyses, e.g. by incorporating data flow information or context
information. •
Mini Project 3.4 Imperative Constructs
In Section 3.5 we showed how to incorporate Data Flow Analysis into our
Control Flow Analysis; this becomes more challenging when imperative con-
structs are added to the language:
Here new7r x : = e1 in e2 creates a new reference variable x to be used in e2;

it is initialised to e 1 , its content is obtained by ! x, and it may be updated
by x : = eo. The creation point for the reference variable is indicated by the
program point 1r E Pnt and the construct e1 ; e2 merely sequences e1 and
e2 (and is equivalent to let x = e1 in e2 when x does not occur in e2).
Exercises 205
One approach to extending the development of Section 3.5 might be to work

with an acceptability relation of the form
where
Vai and C(f) describes the values that the subexpression

• C : Lab ----.
labelled f may evaluate to,
• p: Var ----. Vai and p(x) describes the values that x might be bound
to,
• Sa : Lab----. (Pnt ----.Val) and Sa(f) describes the states that may be
possible before the subexpression labelled f is evaluated,
• S. : Lab ----. (Pnt ----.Val) and S.(f) describes the states that may be
possible after the subexpression labelled f is evaluated, and
• me : Var ----. Pnt and me(x) indicates the creation point for the refer-
ence variable x.
One choice of Vai is P(Term) x L where the first component tracks functions
and the second component tracks abstract values. It may be helpful to devise
a Structural Operational Semantics for the extended language and to use it
as a guide when defining the acceptability relation.
A more advanced treatment would involve context information in the manner
of Section 3.6. •
Exercises
Exercise 3.1 Consider the following expression (omitting labels):
let f = fn x => x 1
in let g = fn y => y+2
in let h = fn z => z+3
in (f g) + (f h)
Add labels to the program and guess an analysis result. Use Table 3.1 to
verify that it is indeed an acceptable guess. •
Exercise 3.2 The specification of the Control Flow Analysis in Table 3.1
uses potentially infinite value spaces and this is not really necessary. To see
this choose some expression e* E Exp that is tobe analysed. Let Var* ~ Var
be the finite set of variables occurring in e*, let Lab* ~ Lab be the finite set
of labels occurring in e*, and let Term* be the finite set of subterms of e*.
Next define
v E Val* = P(Term:l_
p E Env*
C E Ciclie*
Var* - t Val*
Lab* - t Val* --
and note that these value spaces are finite. Show that the specification of
th~nalysi~ Table 3.1 stiH makes sense when (C, P) is restricted to be in
Cache* x Env *. •
Exercise 3.3 Modify the Control Flow Analysis of Table 3.1 to take ac-
count of the left to right evaluation order imposed by a call-by-value se-
mantics: in the clause [app] there is no need to analyse the operand if the
operator cannot produced any closures. Try to find a program where the
modified analysis accepts analysis results (C, P) rejected by Table 3.1. •
Exercise 3.4 So far we have defined "(C, P) is an acceptable solution for

e" to mean that
(3.8)
but an alternative condition is that
(3.9)
Show that (3.8) implies (3.9) but not vice versa. Discuss which of (3.8) or
(3.9) is the preferable definition. •
Exercise 3.5 Consider an alternative specification ofthe analysis in Table

3.1 where the condition
(fun f X=> t~0 ) E p(f)

in [app] is replaced by
C(t1) ~ p(f)
also in [app]. Show that the proof of Theorem 3.10 can be modified accord-
ingly. Discuss the relative precision of the two analyses. •
Exercise 3.6 Reconsider our decision to use Vai= P(Term) and con-
sider using Vai = P(Exp) instead. Show that the specification of the Con-
trol Flow Analysis may be modified accordingly but that then Fact 3.11 (and
hence the correctness result) would fail. •
Exercises 207
Exercise 3. 7 The operational semantics allow us to rename bound vari-

ables without changing the semantics; this is in accord with the language
being statically scoped (or lexically scoped) rather than dynamically scoped.
As an example
and clearly the two programs have the same semantics.

However, renaming bound variables changes the acceptability of a solution as
well as influences the precision of the analysis specified in Table 3.1. Develop
an abstract specification of a 0-CFA analysis that is more faithful to the static
scoping than that of Table 3.1; it should agree with the specification of Table
3.1 for expressions that do not have multiple defining occurrences. •
Exercise 3.8 In Section 3.2 we equipped FuN with a call-by-value seman-

tics. An alternative would be to use a call-by-name or lazy semantics. It can
be obtained as a simple modification of the semantics of Tables 3.2 and 3.3 by
allowing the environments p E Env to map variables to intermediate terms
(and not just values), by deleting the rules [app 2 ] and [let1 ] and then make
some obvious modifications to the axioms [varj, [app.fn], [appfunl and [let2];
in the case of [var] we will take:
p f- xe --+ ite if x E dom(p) and it= p(x)
Complete the specification of the semantics and show that the correctness
result (Theorem 3.10) stiH holds for the analysis of Table 3.1.
What does that tell us about the precision of the analysis? •
Exercise 3.9 Let ~~ and ~~ be two relations satisfying the specification
of Table 3.5. Show that
(C, P) ~~ e iff (C, P) ~~ e
by structural induction on e. •
Exercise 3.10 Consider Proposition 3.18 and determine whether or not
the statement
holds in general. •
Exercise 3.11 Give an example showing that both of the statements
if (C, p) ~ e* then (C, p) ~ 8 e*
.- ........ .-T T ........
if (C, PJ ~ e* and (C, p) (;;;; (C*, p*) then (C, PJ ~ 8 e*
fail in general. •
Exercise 3.12 Give a direct proof of the correctness of the syntax di-
rected analysis of Table 3.5, i.e. establish an analogue of Theorem 3.10. This
involves first extending the syntax directed analysis to the bind- and close-
constructs and next proving that if p R p, p f--ie --+ ie' and (C, p) Ps ie then
also (C,p) Ps ie'. •
Exercise 3.13 Consider the system c;[e*] that contains a constraint

ls1 U · · · U lsn = rhs
whenever C*[e*] contains the n 2: 1 constraints
Show that
(C, p) Pc c;[e*] implies (C, p) Pc C*[e*]
where (C, p) Pc (ls = rhs) is defined in the obvious way. Also show that
holds in the special case where (C, p) is least such that (C, p) Pc C* [e*]. •
Exercise 3.14 Use the ideas of Exercise 3.3 to develop an improvement

of Table 3.8 where expressions are only analysed when absolutely needed.
Next develop a syntax directed analysis using the same ideas. Discuss the
relationship between the two specifications: are they more closely related
than is the case for p and Ps of Table 3.1 and 3.5 (see Exercises 3.10 and
3.11)? •
Exercise 3.15 Modify the abstract specification of the uniform k-CFA

analysis so that it does not record the last k function calls but the last k
times we called a different function than in the preceding call: if the calling
sequence is [1,2,2,1,1] then 2-CFA records [1,1] but the modified analysis
records [2,1]. Discuss which of the two analyses (say for k = 2) is likely to
be most useful in practice. •
Exercise 3.16 Let us consider a language of first-order recursion equation

schemes: the programs have the form
where D* is a sequence of function definitions of the form:
f(x)= e
Exercises 209
Here f is a function name, x is the formal parameter and e is the body of

the function; the functions defined in D may be mutually recursive and the
parameter mechanism is call-by-value. The expressions are given by
e .. - t€
t .. - c 1x 1 f e 1 if eo then e1 else e2 1 e1 op e2
where c E Const and op E Op as before; we shall assume that f and x

belong to distinct syntactic categories. As an example we may define the
Fibonacci function by the following expression (omitting labels):
define fib(z) if z<3 then O

else fib (z-1) + fib (z-2)
in fib x
Define a uniform k-CFA analysis for this language. For k = O and k = 1

compare the development with that for the procedure language in Section
2.5. •
Exercise 3.17 In Subsection 3.6.2 we covered the Cartesian Production

Algorithm based on the assumption that all function abstractions are closed.
In this exercise we do not make this simplifying assumption and also we
wish to deal with recursive functions. Develop an abstract specification of an
analysis
where 8 E ~ is as in Subsection 3.6.2 and
ce E CEnv =Var---.~
Hint: Modify Table 3.10 to deal with functions taking m arguments and
to perform the appropriate determination of new contexts in the clause for
function application. •
Chapter 4
Abstract Interpretation
The purpose of this chapter is to convey some of the essential ideas of Ab-
stract Interpretation. We shall mainly do so in a programming language
independent way and thus focus on the design of the property spaces, the
functions and computations upon them, and the relationships between them.
We first formulate a notion of correctness for a restricted class of analyses
as this will allow us to motivate better some of the key definitions in the
development. Then we cover the widening and narrowing techniques that can
be used to obtain approximations of the least fixed point and for limiting the
number of computation steps needed. Next we consider Galois connections
and Galois insertions that allow a costly space of properties to be replaced
with one that is less costly. Galois connections can be constructed in a
systematic way and can be used to induce one specification of an analysis
from another.
4.1 A Mundane Approach to Correctness

To set the scene, imagine some programming language. Its semantics iden-
tifies some set V of values (like states, closures, double precision reals) and
specifies how a program p transforms one value v1 to another v2; we may
write
(4.1)
for this without committing ourselves to the details of the semantics and
without necessarily imposing determinacy (that p f- V1 "'-+ V2 and p f- V1 "'-+ V3
imply v2 = v3).
In a similar way, a program analysis identifies the set L of properties (like
shapes of states, abstract closures, lower and upper bounds for reals) and
212 4 Abstract Interpretation
specifies how a program p transforms one property lt to another l2 ; we may

write
(4.2)
for this without committing ourselves to the method used for specification
of the analysis. However, unlike what is the case for the semantics, it is
customary to require 1> to be deterministic and thereby define a function;
this will allow us to write /p(h) = l2 to mean p f- lt 1> h.
In the rest of this section we shall show how to relate the semantics to the
analysis. We shall present two approaches based on correctness relations and
representation functions, respectively. In both cases we shall define a notion
of correctness of the analysis with respect to the semantics and we shall show
that the two notions are equivalent.
This is a mundane approach in the sense that it only applies to analyses
where properties directly describe sets of values. This is the case for the
Constant Propagation Analysis of Section 2.3, the Shape Analysis of Section
2.6 and the Control Flow Analysis of Chapter 3 but it is not the case for
the Live Variable Analysis of Section 2.1 where properties are related to
relations between values. In the literature, the terms first-order analyses
versus second-order analyses have been used to differentiate between these
classes of analyses. It is important to stress that the development of Sections
4.2 to 4.5 apply equally well to both classes.
We begin by showing how the development of Chapters 2 and 3 can be
rephrased in the style of (4.1) and (4.2).
Example 4.1 Consider the WHILE language of Chapter 2. Recall that

the semantics is a Structural Operational Semantics with transitions of the
forms (S, a) --+ (S', a') and (S, a) --+ a', where S and S' are statements of
Stmt and a and a' are states of State = Var --+ Z. With S* being the
program of interest we shall now write
for the reflexive transitive closure of the transition relation, i.e. for:
Note that the set V of values is the set State.

We shall now consider the Constant Propagation Analysis of Section 2.3.
Recall that the analysis of S* gives rise to a set of equations cp= formulated
in terms of an instance of a Monotone Framework: the properties L of interest
are given by Statecp =(Var*--+ zT)J_, E is {init(S*)}, Fis How(S*), and ~
is >.x.T. Further recall that a solution to the equations is a pair (CPa,CP.)
4.1 A Mundane Approach to Correctness 213
of mappings CP o : Lab* --+ S"ta1ecp and CP • : Lab* --+ S"ta1ecp satisfying

the equations. Given a solution (CPa, CP.) to cp= we take
to mean that:
Thus for a program S* with isolated entries, â1 is the abstract state associated
with the entry point of s*' and â2 is the abstract state associated with the
exit points; we use the least upper bound operation (U) on the complete
lattice s"ta1ecp to combine the contributions from the (possibly severa!) exit
points of s*. •
Example 4.2 Consider the FuN language of Chapter 3. Recall that the
semantics is given by a Structural Operational Semantics with transitions
of the form p t- ie --+ ie' where p is an environment (an element of Env =
Var --+fin Val) and ie and ie' are intermediate expressions from IExp. Now
let e* be the closed expression of interest. We shall write
to mean that e* when given the argument v1 will evaluate to the value v2,
i.e. that
[] t- (e* vfl /2 --+* v~2
where f1 and f2 are fresh labels. Note that the set V of values now is the set
Val.
We shall next consider the pure Control Flow Analysis of Section 3.1. Recall
that the result of analysing the expression e* is a pair (C, PJ satisfying (C, p) f=
e* as defined in Table 3.1. Here C is an element of c;clle = Lab* --+ Val
and p is an element of EnV =Var* --+Vai where Vai = P(Term*). For
this analysis we shall take the properties L of interest to be pairs (p, v) of
EnV x Vai and assume that (C, p) f= (e* cl 1 )l 2 for some constant c. Then
we define
e* t- (Pi., v!) 1> (p2, v2)
to mean that when e* is given an argument with property CP1, v1) then the
result of the application will have property (ih v2):
C(R1) = v1 A C(t2) = v2 A ii1 = ii2 =ii

Note that the "dummy" constant c used as an argument to e* is used as a
place holder for ali potential arguments being described by v1 ; for this idea
to work it is important that the analysis of c puts no constraints on (C, p) as
in indeed the case for the specification in Table 3.1. •
4.1.1 Correctness Relations

Every program analysis should be correct with respect to the semantics. For a
class of (so-called first-order) program analyses this is established by directly
relating properties to values using a correctness relation:
R :V x L ---> { true, false}
The intention is that v R l formalises our claim that the value v is described
by the property l.
Correctness formulation. To be useful one has to prove that the

correctness relation R is preserved under computation: if the relation holds
between the initial value and the initial property then it also holds between
the final value and the final property. This may be formulated as the impli-
cation
and is also expressed by the following diagram:
p f--
R R
p f-- [>
A relation R satisfying a condition like this is often called a logical relation

and the implication is sometimes written (p f-- • -vt ·) ( R ---* R) (p f-- • [> ·).
The theory of Abstract Interpretation comes to life when we augment the set
of properties L with a preorder structure and relate this to the correctness
relation R. The most common scenario is when L = (L, ~' U, n, j_, T) is a
complete lattice with partial ordering ~ (see Appendix A). We then impose
the following relationship between R and L:
V Rh A h ~ l2 ::::} V R l2 (4.4)
(Vl EL'~ L: v R l) ::::} v R (nL') (4.5)
Condition (4.4) says that the smaller the property is with respect to the
partial ordering, the better (i.e. more precise) it is. This is an "arbitrary''
decision in the sense that we could instead have decided that the larger the
property is, the better it is, as is indeed the case in much of the literature on
Data Flow Analysis; luckily the principle of duality from lattice theory (see
the Concluding Remarks) tells us that this difference is only a cosmetic one.
Condition (4.5) says that there is always a best property for describing a
value. This is important for having to perform only one analysis (using the
best property, i.e. the greatest lower bound of the candidates) instead of
several analyses (one for each of the candidates). Recall from Appendix A
that a subset Y of Lis a Moore family if and only if (nY') E Y for all subsets
Y' of Y. We can then see that condition (4.5) is equivalent to the demand
that {li v R l} is a Moore family.
Condition (4.5) has two immediate consequences:
vRT
vRh 1\ v R l2 * v R (h n l2)
The first formula says that T describes any value and the second formula says
that if we have two descriptions of a value then their greatest lower bound is
also a description of the value.
Example 4.3 Returning to the Constant Propagation Analysis of Exam-

ple 4.1 we can now specify the relation
Rcp : State x SWecp -+ { true,Ealse}
between the values (i.e. the states) and the properties (i.e. the abstract
states):
a Rcp â iff Vx E FV(S*): (â(x) =T V a(x) = â(x))

Thus â may map some variables to T but if â maps a variable x to an element
in Z then this must also be the value of a(x).
Let us observe that the conditions (4.4) and (4.5) are fulfilled by the Con-
stant Propagation Analysis. Recall from Section 2.3 that (SWecp, ~CP) is
a complete lattice with the ordering ~CP· It is then straightforward to verify
that (4.4) and (4.5) do indeed hold. (Also compare with Exercise 2.7.) •
Example 4.4 For the Control Flow Analysis mentioned in Example 4.2
we shall define
RcFA :Val x (:E;;v x Val)-+ { true,false}

to be the relation V of Section 3.2:
v RcFA (P, v) iff v v (P, v)

Recall that we have two kinds of values v E Val, constants c and closures
close t in p, and that V is given by:
V (~ ~) .ff { true if v = c
v p,v I tE vi\ \:fx E dom(p): p(x) V (p,p(x)) ifv =closet in p
The correctness condition (4.3) can be reformulated as
(vi V (p, vi) 1\ [] f- (e* vf' )R 2 ---+* v~ 2 1\ (C, p) f= (e* cR' )R 2 1\

C(CI) =VI 1\ C(C2) = v2) :::} v2 V (p, v2)
and it follows from the correctness result established by Theorem 3.10 in
Section 3.2 (see Exercise 4.3).
Finally, let us observe that the Control Flow Analysis also satisfies the con-
ditions (4.4) and (4.5). For this we shall equip &v x Vai with the partial
ordering ~CFA defined by:
--
This will turn Env x Val into a complete lattice. By induction on v E Val
one can then easily prove that (4.4) and (4.5) are fulfilled. •
4.1.2 Representation Functions
An alternative approach to the use of a correctness relation R : V x L ---+

{ true, false} between values and properties is to use a representation function:
{J:V---+L
The idea is that f3 maps a value to the best property describing it. The
correctness criterion for the analysis will then be formulated as follows:
This is also expressed by the following diagram:
p f-
f3 1 1 f3
p f- l>
Thus the idea is that if the initial value VI is safely described by h then the
final value v2 will be safely described by the result l2 of the analysis.
Equivalence of correctness formulations. Lemma 4.5 below

shows that the formulations (4.3) and (4.6) of the correctness of the analysis
are indeed equivalent (when R and {3 are suitably related). To establish
this we shall first show how to define a correctness relation Rf3 from a given
representation function {3:
v Rf3 l iff {3(v) r;;;, l
Next we show how to definea representation function f3R from a correctness
relation R:
f3R(v) = n{l/ V R l}
Lemma 4.5
(i) Given {3: V---+ L, then the relation R(3 : V x L---+ { true, false} satisfies
conditions (4.4) and (4.5), and furthermore f3R 13 = {3.
(ii) Given R: V x L---+ {true,false} satisfying conditions (4.4) and (4.5),
then f3R is well-defined and Rf3n = R.
Hence the two formulations (4.3) and (4.6) of correctness are equivalent. •
Proof To prove (i) we first observe that condition (4.4) is immediate since [;;; is
transitive. Condition (4.5) is immediate because when (J(v) is a lower bound for L'
we have (J(v) [;;; nL'. The calculation f3R/3(v) = n{ll V R/3 l} = n{ll (J(v) [;;; l} =
(J(v) then concludes the proof of (i).
To prove (ii) we observe that from v R l we get f3R(v) [;;; l and hence v R13n l.
Conversely, from v R13n l we get f3R(v) [;;; l; writing L' = {l v R l} it is clear that
1
(4.5) gives v R (nL') and this amounts tov R (f3R(v)); we then get the desired
result v R l by (4.4). •
Motivated by these results we shall say that the relation R is generated by

the representation function {3 whenever v R lis equivalent to {3(v) [;;; l. This
relationship is illustrated in Figure 4.1: The relation R expresses that v is
described by all the properties above (3( v) and (3 expresses that among all
the properties that describe v, f3(v) is the best.
Example 4.6 For the Constant Propagation Analysis studied in Exam-

ples 4.1 and 4.3 we shall define
f3cp : State ---+ -

Statecp
as the injection of State into SWecp: f3cp(a) = .Xx.a(x). It is straightfor-
ward to verify that Rcp is generated by f3cp, i.e.
a Rcp â <==? f3cp(a) f;;;,cp â
using the definition of the ordering f;;;,cp on SWecp. •
Figure 4.1: Correctness relation R generated by representation function (3.
Example 4. 7 For the Control Flow Analysis studied in Examples 4.2 and
--
4.4 we shall define
f3cFA : Val ---+ Env x Val
inductively on the structure of values v E Val:
if v = c
{ (Ax.0, 0)
f3cFA (v) = (f3t'FA (p), { t}) if v = close t in p
The first clause reflects that we do not collect constants in a pure 0-CFA
analysis. In the second clause we only have one closure so the abstract value
will be a singleton set and we construct the associated "minimal" abstract
environment by extending f3cFA to operate on environments. To do that
we shall "merge" all the abstract environments occurring in U{f3cFA(p(x)) 1
x E Var*}; this reflects that the 0-CFA analysis uses one global abstract
environment to describe all the possible local environments of the semantics.
So we define f3t'FA : Env ---+ ~ by:
u{IJ'y(x) 1 f3cFA(p(y)) = (Îly, Vy) and y E dom(p)}

U{ fix if x E dom(p) and /3cFA(p(x)) = (px, Vx)
0 otherwise
To show that RcFA is generated by f3cFA we have to show that:
V RcFA (p, v) {::} f3cFA (V) ~CFA (p, v)

This follows by induction on v E Val and we leave the details to Exercise
4.4. •
4.1.3 A Modest Generalisation

We shall conclude this section by performing a modest generalisation of the
development performed so far. A program p specifies how one value v1 is
transformed into another value v2 :
Here vl E vl and V2 E v2 and we shall subsequently refrain from imposing

the condition that V1 = V2; thus we shall allow the programs to have differ-
ent "argument" and "result" types - for example, this will be the case for
most functional programs. The analysis of p specifies how a property h 1s
transformed into a property l 2 :
Here h E L 1 and l 2 E L2 and again we shall refrain from imposing the

restriction that L 1 = L 2 . As previously argued it is natural to demand that
p f- h 1> h specifies a function
given by fv(ld = l2 iff p f- h 1> l2.

Turning to the correctness conditions we shall now assume that we have two
correctness relations, one for Vi and L 1 and one for V2 and L 2 :
R1 : V1 x L1 ___, { true,false} generated by fJ1 : V1 ---t L1

R2 : v2 X L2 ---t { true, false} generated by !32 : v2 ---t L2
Correctness of fv now amounts to
for all Vl E vl, V2 E v2 and h E Ll. Using the concept of logica[ relations
(briefty mentioned above) this can be written as:
To be precise,'"'"" (R1 ---» R2) f means that:
Higher-order formulation. We can now ask whether the relation

R 1 ---» R 2 defined above is a correctness relation. Lemma 4.8 below shows
that this is indeed the case and furthermore that we can find a representation
function f3 such that R1 ---» R2 is generated by j]. The representation function
{3 can be defined from the representation functions {31 and {32 and it will be
denoted {31 ----* fJ2:
({31----* !32)(~) = Ait.U{f32(v2) 1 {31(vl) ~ h 1\ v1 ~ v2}
Lemma 4.8 If Ri is a correctness relation for Vi and Li that is generated

by the representation function f3i : Vi ----+ Li (for i = 1, 2) then R1 ----* R2
is a correctness relation and it is generated by the representation function
!31 - !32· •
Proof We shall prove "'-'+ (RI -» R2) f <:::} (f3I -» (32)("-+) [::; f. We calculate:
(f3I-» (32)("-+) [::; f <:::} Vli: U{f32(v2) f3I(v!) [::; h

1 1\ VI"'-'+ v2} [::; f(l!)
<:::} \fh, VI, V2 : (fJI (VI) ~ h 1\ VI "'-'+ V2 =? (32 (V2) [::; f (h))
<:::} Vh,vi,V2: (viRI h /\VI"'-'+ V2 =? V2 R2 f(h))
<:::} "'-'+ (RI -» R2) f
Note that it now follows (from Lemma 4.5) that if each R; satisfies conditions (4.4)
and (4.5) then so does RI -» R2. •
Example 4.9 Consider the program plus with the semantics given by
plus 1- (zt, z2) ~ z1 + z2
where z 1, z2 E Z. A very precise analysis might use the complete lattices
(P(Z), ~) and (P(Z x Z), ~) as follows:
fpius(ZZ) = { Z1 + Z2 (zt, Z2)1 E ZZ}
where ZZ ~ Z x Z. Consider now the correctness relations Rz and Rzxz
generated by the representation functions:
f3z(z) {z}
f3zxz(zt, z2) = {(zt, z2)}
The correctness of the analysis of plus can now be expressed by
Vz1, z2, z, ZZ: plus 1- (z1, z2) ~ z 1\ (z1, z2) Rzxz ZZ ::::} z Rz fpius(ZZ)
or more succinctly
(plus 1- · ~ ·) (Rzxz ----* Rz) !plus

The representation function f3z x z ----* f3z satisfies
so the correctness can also be expressed as (f3z xz ----* f3z) (plus 1- · ~ ·) ~

fplus· •
: _.•.. [-oo,ooj
'._[-oo,lj
./~-l,oc}
O} [-2,2} . [O,ocj
•• 1 , 1 [-2,1} [-1,2} .. [1,ooj
[-2,0}
Figure 4.2: The complete lattice Interval= (Interval,~).
The above example illustrates how the abstract concepts can give a more
succinct formulation of the correctness of the analysis. In the following we
shall see several cases where we move freely between what we may call a
"concrete" formulation of a property and an "abstract" formulation of the
same property. And we shall see that the latter often will allow us to reuse
general results so that we do not have to redevelop parts of the theory for
each application considered.
4.2 Approximation of Fixed Points

It should be clear by now that complete lattices play a crucial role in program
analysis and in the remainder of this chapter we shall tacitly assume that
property spaces such as L and M are indeed complete lattices. We refer to
Appendix A for the basic notions of complete lattices and monotone func-
tions. The following example introduces an interesting complete lattice that
forms the hasis of many analyses over the integers.
Example 4.10 We shall now present a complete lattice that may be used
for Array Bound Analysis, i.e. for determining if an array index is always
within the bounds of the array- if this is the case then a number of run-time
checks can be eliminated.
The lattice (Interval, r::;::) of intervals over Z may be described as follows.
The elements are
where the ordering ~ on Z is extended to an ordering on Z' = Z U { -oo, oo}

by setting -oo ~ z, z ~ oo, and -oo ~ oo (for all z E Z). Intuitively, .1
denotes the empty interval and [z1, z2] is the interval from z1 to z2 including
the end points if they are in Z. We shall use int to range over elements of
Interval.
The partial ordering ~ on Interval is depicted in Figure 4.2; the idea is that
int1 ~ in~ corresponds to {z 1 z is in int1} ~ {z 1 z is in int2} where the
meaning of "is in" should be immediate. To give a succinct definition of the
partial ordering we define the infimum and supremum operations on intervals
as follows:
inf( int) = { ()()
Zl
if int = .1
if int = [zi. z2]
sup( int) { -()()
Z2
if int = .1
if int = [z1, z2]
This allows us to define:
int1 ~ int2 iff inf(in~) ~ inf(intl) A sup(inl!) ~ sup(int2)
We claim that (Interval, ~) is indeed a complete lattice. We shall prove this

by showing that each subset of Interval has a least upper bound and then
refer to Lemma A.2 of Appendix A to get that (Interval, ~) is a complete
lattice. So let Y be a subset of Interval. The idea is that each interval int
of Y should be "contained in" the interval U Y defined by:
.1 ifY ~ {.1}
UY = { [ inf'{inf(int) 1 intE Y}, sup'{sup(int) 1 intE Y}]
otherwise
where inf' and sup' are the infimum and supremum operators on Z' corre-
sponding to the ordering ~ on Z'; they are given by inf'(0) = oo, inf'(Z) = z'
if z' E Zis the least element of Z, and inf'(Z) = -oo otherwise; and simi-
larly sup'(0) = -oo, sup'(Z) = z' if z' E Zis the greatest element of Z, and
su p' (Z) = oo otherwise. It is now straightforward to show that UY is indeed
the least upper bound of Y. •
Given a complete lattice L = (L, ~. U, n, .1, T) the effect of a program, p, in

transforming one property, h, into another, l2, i.e. p f- h 1> l2, is normally
given by an equation
for a monotone function f : L --+ L dependent on the program p. Note

that the demand that f is monotone is very natural for program analysis; it
merely says that if l~ describes at least the values that h does then also f(l~)
describes at least the values that f(h) does.
For recursive or iterative program constructs we ideally want to obtain the
least fixed point, lfp(f), as the result of a finite iterative process. However,
the iterative sequence (r (l.) )n need not eventually stabilise nor need its least
upper bound necessarily equal lfp(f). This might suggest considering the
iterative sequence (fn(T))n and, even when it does not eventually stabilise,
we can always terminate the iteration at an arbitrary point in time. While
this is safe (thanks to condition (4.4) of Section 4.1) it turns out tobe grossly
imprecise in practice.
Fixed points. We shall begin by recalling some of the properties of fixed

points of monotone functions over complete lattices; we refer to Appendix
A for the details of this development. So consider a monotone function f :
L --+ L on a complete lattice L = (L, ~' U, n, 1., T). A fixed point of f is an
elementlE L such that f(l) = l and we write
Fix(!) = {li f(l) = l}

for the set of fixed points. The function f is reductive at l if and only if
f(l) ~ l and we write
Red(f) = {l 1 f(l) ~ l}
for the set of elements upon which f is reductive; we shall say that f itself
is reductive if Red(f) = L. Similarly, the function f is extensive at l if and
only if f(l) ;:) l and we write
Ext(f) = {li f(l) ;:) l}

for the set of elements upon which f is extensive; we shall say that f itself is
extensive if Ext(f) = L.
Since L is a complete lattice it is always the case that the set Fix(!) will have
a greatest lower bound in L and we denote it by lfp(f); this is actually the
least fixed point of f because Tarski's Theorem (Proposition A.lO) ensures
that:
lfp(f) = nFix(!) = n Red(f) E Fix(!) <;;; Red(f)
Similarly, the set Fix(!) will have a least upper bound in L and we denote
it by gfp(f); this is actually the greatest fixed point of f because Tarski's
Theorem ensures that:
gfp(f) = UFix(!) = UExt(f) E Fix(!) <;;; Ext(f)
In Denotational Semantics it is customary to iterate to the least fixed point by

taking the least upper bound ofthe sequence (r(l-))n· However, we have not
Red(f)- - - -
nnr(T)
gip(f)
lip(!)
Ext(f) - - - -
.l
Figure 4.3: Fixed points of f.
imposed any continuity requirements on f (e.g. that f(Unln) = UnU(ln))

for all ascending chains (ln)n) and consequently we cannot be sure to actually
reach the fixed point. In a similar way one could consider the greatest lower
bound of the sequence (r(T))n. One can show that
as is illustrated in Figure 4.3; indeed all inequalities (i.e. ~) can be strict

(i.e. =tf).
4.2.1 Widening Operators

Since we cannot guarantee that the iterative sequence (fn(.l))n eventually
stabilises nor that its least upper bound necessarily equals lip(!), we must
consider another way of approximating lip(!). The idea is now to replace
it by a new sequence Uv )n that is known to eventually stabilise and to do
so with a value that is a safe (upper) approximation of the least fixed point.
The construction of the new sequence is parameterised on the operator 'V,
called a widening operator; the precision of the approximated fixed point as
well as the cost of computing it depends on the actual choice of widening
operator.
U pper bound operators. In preparation for the development, an

operator O : L x L-+ L on a complete lattice L = (L, !;;;;) is called an upper
bound operator if
for all h, l2 E L, i.e. it always returns an element larger than both its ar-
guments. Note that we do not require O to be monotone, commutative,
associative, nor absorptive (i.e. that l O l = l).
Let (ln)n be a sequence of elements of L and let cp : L x L -+ L be a total
function on L. We shall now use cp to construct a new sequence (l~)n defined
by:
l ifn=O
l~ = { :
ln-l c/J ln ifn >O
The following result expresses that any sequence can be turned into an as-
cending chain by an upper bound operator:
Fact 4.11 If (ln)n is a sequence and O is an upper bound operator then

(l~)n is an ascending chain; furthermore l~ :;;;) U{lo, h, · · ·, ln} for all n. •
Proof To prove that (l~)n is an ascending chain it is sufficient to prove that
l~ [; l~+l for all n. If n = O we calculate l~ = la !;;;; la O h = l~. For the inductive
step we have l~ [; l~ O ln+l = l~+l as required.
To prove that l~ ;;;) U{la, h, · · · , ln} we first observe that it holds trivially for
n =O. For the inductive step we have l~+l = l~ O ln+l ;;;) U{la, h, · · ·, ln} U ln+l =
U{la, h, · · ·, ln, ln+l} and the result follows. •
Example 4.12 Consider the complete lattice (Interval,!;;;;) of Figure 4.2

and let int be an arbitrary but fixed element of Interval. Consider the
following operator Oint defined on Interval:
. t • int . +~ { int1 U in~ if int1 !;;;; int V int2 !;;;; int1

zn 1 u znv.<l = .
[-oo, oo] otherw1se
Note that the operation is not symmetric: for int = [0, 2] we e.g. have
[1, 2]0int [2, 3] = [1, 3] whereas [2, 3]0int [1, 2] = [-oo, oo].
It is immediate that Oint is an upper bound operator. Consider now the
sequence:
[0, O], [1, 1], [2, 2], [3, 3], [4, 4], [5, 5], · · ·
If int = [O, oo], then the upper bound operator will transform the above
sequence into the ascending chain:
[0, O], [0, 1], [0, 2], [O, 3], [O, 4], [O, 5], · · ·
f V'm _ jm+1 _
-V' -···
Red(f) - - - - - •
lfp(f) - - - - - - - - - - - - - - -
~~
~~
~~ = _l
Figure 4.4: The widening operator \7 applied to f.
However, if int = [O, 2], then we will get the following ascending chain
[0, O], [0, 1], [0, 2], [0, 3], [-oo, oo], [-oo, oo], · · ·
which eventually stabilises.
•
Widening operators. We can now introduce a special class of upper
bound operators that will help us to approximate the least fixed points: An
operator \7 : L x L __, L is a widening operator if and only if:
• it is an upper bound operator, and
• for all ascending chains (ln)n the ascending chain (t;;:)n eventually sta-
bilises.
Note that it follows from Fact 4.11 that (t;;:)n is indeed an ascending chain.
The idea is as follows: Given a monotone function f : L __, L on a com-
plete lattice L and given a widening operator \7 on L, we shall calculate the
sequence (!!!; )n defined by
if n =O
if n > O 1\ f(f~- 1 ) [::; ~~- 1
otherwise
As in Fact 4.11 it follows that this is an ascending chain and Proposition 4.13
below will ensure that this sequence eventually stabilises. From Fact 4.14
below we shall see that this means that we will eventually have f(!V') ~ fv
for some value of m (corresponding to the second clause in the definition
of fv)· This means that fis reductive at fv and from Tarski's Theorem
(Proposition A.10) we then know that fv ;;! lip(!) must be the case; hence
we take
lEpvU) =!V'
as the desired safe approximation of lip(!). This is illustrated in Figure 4.4.
We shall now establish the necessary results.
Proposition 4.13
If V' is a widening operator then the ascending chain Uv )n even-
tually stabilises.
In preparation for the proof of Proposition 4.13 we shall first show the fol-
lowing technical result:
Fact 4.14 If V' is a widening operator then:

(i) the sequence Uv )n is an ascending chain;
(ii) if f(!V') ~ fv for some m then the sequence Uv )n eventually stabilises
and furthermore Vn > m : fv = fv and Un fv = !V';
(iii) if Uv)n eventually stabilises then there exists an m such that f(!V') ~
fV'; and
(iv) if Uv )n eventually stabilises then Un fv ;;! lfp(f).
These claims also hold if V' is just an upper bound operator. •
Proof The proof of (i) is analogous to that of Fact 4.11 so we omit the details.
To prove (ii) we assume that f(JV') [;;; fv for some m. By induction on n > m
we prove that fv = fv: for n = m + 1 it follows from the assumption and for the
inductive step we note that !Uv) [;;; fv will be the case so J;+l = fv· Thus Uv)n
eventually stabilises and it follows thatUn fv = fv.
To prove (iii) we assume that Uv )n eventually stabilises. This means that there
exists m such that "'n > m : fv = fv. By way of contradiction assume that
f(JV') [;;; fv does not hold; then fv = r;+l = fv V' f(JV') ;;J f(JV') and we have
the desired contradiction.
To prove (iv) we observe that (ii) and (iii) give Un
fv = fv for some m where
f(JV') [;;; fv· Hence fv E Red(f) and by Tarski's Theorem (Proposition A.lO)
this shows fv ;;J lfp(f). •
We now turn to the proof of Proposition 4.13:

Proof By way of contradiction we shall assume that the ascending chain (!!!; )n
never stabilises; i.e.:
'Vno : :ln :::: no : J!!J =1- f~,O
It follows that J(f;- 1 ) C J;- 1 never holds for any n > O; because if it did,
then Fact 4.14 gives that (f!!;)n eventually stabilises and our hypothesis would be
contradicted. This means that the definition of (!!!; )n specialises to:
if n =O
otherwise
Now define the sequence (ln)n by
if n =O
if n >O
and note that (ln)n is an ascending chain because (!!!; )n is an ascending chain (Pact
4.14) and fis monotone. We shall now prove that
'Vn: z;: = !!!7

by induction on n: for n =o it is immediate and for n >o we have z;: = z;:_1 \7 ln =
J;- 1 \7 JU;- 1 ) = f!!J. Since (ln)n is an ascending chain and \7 is a widening op-
erator it follows that the sequence u;:)n eventually stabilises, i.e. (!!!; )n eventually
stabilises. This provides the desired contradiction and proves the result. •
Example 4.15 Consider the complete lattice (Interval,[;;;) ofFigure 4.2.

Let K be a finite set of integers, e.g. the set of integers explicitly mentioned
in a given program. We shall now define a widening operator VK based on
K. The idea is that [zi, z2] VK [z3, z4] is something like
where LB(zi, z3) E {zi} U K U { -oo} is the best possible lower bound and
UB(z2, z4) E {z2} U K U {oo} is the best possible upper bound. In this way
a change in any of the bounds of the interval [zi, z2] can only take place in a
finite number of steps (corresponding to the elements of K).
For the precise definition we let Zi E Z' = Z U { -oo, oo} and write:
{
ZI if ZI :::; Z3
LBK(ZI, Z3) k if Z3 <ZI 1\ k = max{k E K 1 k:::; z3}
-00 if Z3 <ZI 1\ \:fk E K : Z3 < k
{
Z2 if Z4 :::; Z2
UBK(Z2, Z4) k if Z2 < Z4 1\ k = mi n{ k E K 1 Z4 :::; k}
00 if Z2 < Z4 1\ \:fk E K : k < Z4
We can now define \7 = VK by:
.l if int1 = int2 = .l
int1 \7 in~= { [ LBK(inf(int!), inf(int2)), UBK(sup(int!),sup(int2))]
otherwise
As an example consider the ascending chain (intn)n:
[O, 1], [O, 2], [O, 3], [O, 4], [0, 5], [0, 6], [0, 7], · ·.
and assume that K = {3, 5}. Then (int~)n will be the chain
[0, 1], [0, 3], [0, 3], [0, 5], [0, 5], [0, oo], [0, oo], · · ·
It is straightforward to show that \7 is indeed an upper bound operator. To

show that it is a widening operator we consider an ascending chain ( intn)n
and must show that the ascending chain (int~)n eventually stabilises. By way
of contradiction suppose that (int~)n does not eventually stabilise. Then at
least one of the following properties will hold:
(\:In: inf(int~) > -oo) 1\ inf(Unint~) = -oo

(\:In: sup(int~) < oo) 1\ sup(Unint~) = oo
Without loss of generality we can assume that the second property holds.
Hence there must exist an infinite sequence n 1 < n 2 < · · · such that
\:fi: oo > sup(int~,+ 1 ) > sup(int~J
and by finiteness of K there must be some j such that
Vi 2: j: oo > sup(int~,+1) > sup(int~,) > max(K)
where for the purpose of this definition we set max(0) = -oo. Since we also
have
it must be the case that sup( intnj+l) > sup( int~j) as otherwise sup( int~j+l)
= su p( int~J ) . But then the construction yields
and we have the desired contradiction. This shows that \7 is a widening

operator on the complete lattice of intervals. •
230 4 Abstract lnterpretation
4.2.2 Narrowing Operators

Using the technique of widening we managed to arrive at an upper approx-
imation fv of the least fixed point of f. However, we have f(/V') !;:;; fv
so f is reductive at fv and this immediately suggests a way of improving
the approximation by considering the iterative sequence (r(!V'))n. Since
fv E Red(f) this will be a descending chain with r Uv) E Red(f) and
hence r Uv) ;;;;) lip(!) for ali n. Once again we have no reason to believe
that this descending chain eventually stabilises although it is of course safe
to stop at an arbitrary point. This scenario is not quite the one we saw above
but inspired by the notion of widening we can define the notion of narrowing
that encapsulates a termination criterion. This development can safely be
omitted on a first reading.
An operator ~ :L x L ~ L is a narrowing operator if:
• lz !;:;; h ::::} l2 !;:;; (h ~ l2) !;:;; h for ali h, lz EL, and

• for ali descending chains (ln)n the sequence (l~)n eventually stabilises.
Note that we do not require ~tobe monotone, commutative, associative or

absorptive. One can show that (l~ )n is a descending chain when (ln)n is a
descending chain (Exercise 4.10).
The idea is as follows: For fv satisfying f(!V')!;:;; /V', i.e. lfpv(f) = fV', we
now construct the sequence ([/]~)n by
n { fv if n =o
[/]~ = [/]~- 1 ~ f([/]~- 1 ) if n >O
Lemma 4.16 below guarantees that this is a descending chain where ali ele-
ments satisfy lip(!) !;:;; [!]~. Proposition 4.17 below tells us that this chain
eventually stabilises so [f]:l' = [/]~'+1 for some value m'. We shall therefore
take
lfp~(f) = [/]:l'
as the desired approximation of lfp(f). The complete development is illus-
trated in Figures 4.4 and 4.5. We shall now establish the required results.
Lemma 4.16 If ~ is a narrowing operator and f(!V')!;:;; fv then ([/]~)n

is a descending chain in Red(f) and
for alin. •
Proof By induction on n we prove:
(4.7)
[JJ~ = fv
[/]1.
~ .............. . [/]:l'-1
~--·········· [/]~' = [/J:l' +1 = ...
lfp(f)
Figure 4.5: The narrowing operator D. applied to f.
For the hasis (n =O) it is immediate that
using that f(!V')!;;; fv· By construction of [!]~+ 1 we then get
!([!]~) !;;; [f]~+l !;;; [!]~
and together these two results estahlish the hasis of the induction proof.
For the inductive step we may apply f to the induction hypothesis (4. 7) and get
since f is assumed to he monotone. Using the induction hypothesis we also have

!([!]~) !;;; [f]~+l so we ohtain:
r+ 2 UV')!:: J([JJ~+l)!:: [JJ~+l

By construction of [!]~+ 2 we get
and together these two results complete the proof of (4.7).

From (4.7) it now follows that ([f]~)n is a descending chain in Red(f). It also
follows that rUV') !:: [!]~ holds for n > o and it clearly also holds for n = o.
From the assumption JUV') ~ !V' it is immediate that f(rUV')) ~ rUV') for
n 2': o and hence rUv) E Red{f). But then rUV') ;;;J lfp(f). This completes the
proof. •
Proposition 4.17
If ~ is a narrowing operator and f Uv) ~ fv then the descending
chain ([f]~)n eventually stabilises.
Proof Define the sequence (ln)n by
ifn =O
ifn >O
and note that this defines a descending chain because ([f]::l..)n is a descending chain
and because f([f]~) ~ fv· Therefore the sequence (l~)n eventually stabilises. We
now prove by induction on n that:
l~ = [f]::l..
The hasis (n = O) is immediate. For the inductive step we calculate l~+I
l~ ~ ln+I [f]::l.. ~f([f]::l..) = [/]'~+ 1 . It thus follows that ([/]::l..)n eventually
stabilises. •
It is important to stress that narrowing operators are not the dual concept
of widening operators. In particular, the sequence Uv )n may step outside
Ext(f) in order to end in Red(f), whereas the sequence ([f]~)n stays in
Red(f) all the time.
Example 4.18 Consider the complete lattice (Interval,~) ofFigure 4.2.

Basically there are two kinds of infinite descending chains in Interval: those
with elements of the form [-oo, z] and those with elements of the form [z, oo]
where z E Z. Consider an infinite sequence of the latter form; it will have
elements
where z1 < z2 < Z3 < · · ·. The idea is now to define a narrowing operator
~N that will force the sequence to stabilise when Zi ~ N for some fixed non-
negative integer N. Similarly, for a descending chain with elements of the
form [-oo, zi] the narrowing operator will force it to stabilise when Zi::; -N.
Formally, we shall define ~ = ~N by
{
.1 if int1 = .1 V in~ = .1
[z1, z2] otherwise
4.3 Galois Connections 233
where
Z1 = { inf( intl)
inf( int2)
if N < inf( in~) 1\ sup( in~) = oo
otherwise
Z2 = { sup( intl)
sup( int2)
if inf(int2) = -oo 1\ sup(int2)
otherwise
< -N
So consider e.g. the infinite descending chain ([n, oo])n
[0, oo], [1, oo], [2, oo], [3, oo], [4, oo], [5, oo], · · ·
and assume that N = 3. Then the operator will give the sequence ([n, oo]Ll)n:
[0, oo], [1, oo], [2, oo], [3, oo], [3, oo], [3, oo], · · ·
Let us show that b. is indeed a narrowing operator. It is immediate to verify
that
in~ ~ int1 implies in~ ~ int1 b. int2 ~ int1
by cases on whether in~ = ..l or in~ =1- ..l. We shall then show that if (intn )n
is a descending chain then the sequence (in~ )n eventually stabilises. So
assume that (intn)n is a descending chain. One can then show that (in~)n
is a descending chain (Exercise 4.10). Next suppose by way of contradiction
that (in~ )n never eventualiy stabilises. It follows that there exists n 1 2: O
such that:
in~ =1- [-oo, oo] for alin 2: n1
It furthermore follows for ali n 2: n1 that in~ must have:
sup(in~) = oo or inf(in~) = -oo

Without loss of generality let us assume that all n 2: n 1 have su p( in~) = oo
and inf(in~) E Z. Hence there exists n2 2: n1 such that:
inf( in~) > N for all n 2: n2
But then in~ = in~2 for all n 2: n2 and we have the desired contradiction.
This shows that b. is a narrowing operator. •
4.3 Galois Connections

Sometimes calculations on a complete lattice L may be too costly or even
uncomputable and this may motivate replacing L by a simpler lattice M. An
example is when L is the powerset of integers and M is a lattice of intervals.
So rather than performing the analysis p f- h C> h in L, the idea will be to
find a description of the elements of L in M and to perform the analysis
p f- m1 1> m2 in M. To express the relationship between L and M it is

customary to use an abstmction function
a:L-+M
giving a representation of the elements of L as elements of M and a concreti-

sation function
"f:M-+L
that expresses the meaning of elements of M in terms of elements of L. We
shall write
(L,a,"f,M)
or
L
--
a
M
for this setup and would expect that a and "1 should be somehow related.
We shall study this relationship in the present section and then return to the
connection between p f- h 1> l2 and p f- m11> m2 in Section 4.5; in Section 4.4
we shall study the systematic construction of such relationships.
We define (L, a, "f, M) to be a Galois connection between the complete lat-
tices (L, !;;;) and (M, !;;;) if and only if
a : L --+ M and "1 : M --+ L are monotone functions
that satisfy:
(4.8)
ao'Y C .>..m.m (4.9)
Conditions (4.8) and (4.9) express that we do not Iose safety by going back
and forth between the two lattices although we may Iose precision. In the
case of (4.8) this ensures that if we start with an elementlE L we can first
find a description a(l) of it in M and next determine which element 'Y(a(l))
of L that describes a(l); this need not bel but it will bea safe approximation
tol, i.e. l!;;; 'Y(a(l)). This is illustrated in Figure 4.6.
Example 4.19 Let P(Z) = tp(Z), ~) be the complete lattice of sets of

integers and let Interval = (Interval,!;;;) be the complete lattice of Figure
4.2. We shall now define a Galois connection
(P(Z), azr, "/zr, Interval)
between P(Z) and Interval.

Figure 4.6: The Galois connection (L, a,"(, M).
The concretisation function '"YZI :Interval-+ P(Z) is defined by
'"Yzr(int) = {z E Z 1 inf(int):::; z:::; sup(int)}
where inf and sup are as in Example 4.10. Thus '"YZI will extract the set of ele-
ments described by the interval, e.g. '"Yzr([O, 3]) = {0, 1, 2, 3} and '"Yzr([O, oo]) =
{z E Z 1 z 2:: 0}.
The abstraction function azr : P(Z) -+ Interval is defined by
z-{.l
azr( ) - [inf'(Z),sup'(Z)]
ifZ=0
otherwise
where inf' and sup' are as in Example 4.10. Thus azr will determine the
smallest interval that includes all the elements of the set, e.g. azr( {0, 1, 3}) =
[0,3] and azr({2*z 1 z >O})= [2,oo].
Let us verify that (P(Z), azr, '"Yzr, Interval) is indeed a Galois connection. It
is easy to see that azr and '"Yzr are monotone functions. We shall next prove
that (4.8) holds, i.e. that '"YZI o azr;;;) >..Z.Z. If Z =/= 0 we have:
'"Yzr( azr(Z)) '"Yzr([inf' (Z), sup' (Z)))

{z E Z 1 inf'(Z):::; z:::; sup'(Z)}
J z
For Z = 0 we trivially have "(zr(azr(0)) = "fzr(.l) = 0 so we have proved
(4.8). Intuitively, this condition expresses that ifwe start with a subset of Z,
find the smallest interval containing it, and next determine the corresponding
subset of Z, then we will get a (possibly) larger subset of Z than the one we
started with.
Finally, we shall prove (4.9), i.e. that azr o 'YZI ~ >.int.int. Consider first
int = [zi. z2] where we have:
azi ({Z E Z 1 Zl :<; Z :<; Z2})

[z1, z2]
For int = ..l we trivially have azrbzr(..l)) = azr(0) = ..l so we have proved
(4.9). Intuitively, the condition expresses that if we start with an interval,
determine the corresponding subset of Z, and next find the smallest interval
containing this set, then the resulting interval will be included in the interval
we started with; actually we showed that the two intervals are equal. •
Adjunctions. There is an alternative formulation of the Galois connec-

tion (L, a,')', M) that is frequently easier to work with. We define (L, a,')', M)
tobe an adjunction between complete lattices L = (L, ~) and M = (M, ~)
if and only if
a :L ---t M and ')' : M ---t L are total functions
that satisfy
a(l) ~ m {:} l ~ 'Y(m) (4.10)
for all l E L and m E M.
Condition (4.10) expresses that a and 'Y "respect" the orderings of the two
lattices: If an element l E L is safely described by the element m E M,
i.e. a(l) ~ m, then it is also the case that the element described by m is safe
with respect tol, i.e. l ~ 'Y(m).
Proposition 4.20
(L, a,')', M) is an adjunction if and only if (L, a,')', M) is a Galois
connection.
Proof First assume that ( L, a., 'Y, M) is a Galois connection and let us show that
it is an adjunction. So assume first that o.(l) ~ m; since 'Y is monotone we get
7(o.(l)) ~ 7(m); using that 7oo.;;;) >..l.l we then get l ~ 7(o.(l)) ~ 7(m) as required.
The proof showing that l ~ 7(m) implies a.(l) ~ m is analogous.
Next assume that (L, a.,"(, M) is an adjunction and let us prove that it is a Galois
connection. First we prove that 'Y o a. ;;;) >..l.l: for l E L we trivially have o.(l) ~ o.(l)
and using that o.(l) ~ m => l ~ 7(m) we get l ~ 7(o.(l)) as required. The proof
showing that a. o 'Y ~ >..m.m is analogous. To complete the proof we also have to
show that a. and 'Y are monotone. To see that a. is monotone suppose that h ~ l2 ;
we have already proved that 'Y o a.;;;) A.l.l so we have h ~ l2 ~ 7(o.(l2)); using that
l ~ 7(m) => a.(l) ~ m we then get o.(h) ~ o.(h). The proof showing that 'Y is
monotone is analogous. •
Galois connections defined by extraction functions. We

shall now see that representation functions (introduced in Section 4.1) can be
used to define Galois connections. So consider once again the representation
function (3 : V ----+ L mapping the values of V to the properties of the complete
lattice L. It gives rise to a Galois connection
(P(V),a,,,L)
between P(V) and L where the abstraction and concretisation functions are
defined by
a(V') = U{f3(v) vE V'} 1
r(l) = {vEVIf3(v)i;;;l}
for V' ~ V and l E L. Let us pause for a minute to see that this indeed
defines an adjunction:
a(V')!;;;; l {:} U{f3(v) 1 vE V'}!;;;; l
{:} VvEV':f3(v)i;;;l
{:} V'~ 1 (t)
It follows from Proposition 4.20 that we also have a Galois connection. It is
also immediate that a( {v}) = (3( v) as illustrated by the diagram:
'
A special case of the above construction that is frequently useful is when

L = (P(D), ~) for some set D and we have an extraction function
TJ:V----+D
mapping the values of V to their descriptions in D. We will then define the
representation function (3ry : V ----+ P(D) by /3ry(v) = {TJ(v)} and the Galois
connection between P(V) and P(D) will now be written
(P(V), ary, /ry, P(D))

where
U{/3ry(v) 1 vE V'} {TJ(v) vE V'}
1
{vE V /3ry(v)
1 ~ D'} {v 1 TJ(v) E D'}
for V' ~ V and D' ~ D. The relationship between 'TJ, (3ry, ary and /ry is
illustrated by the diagram:
{0,+}
{+}
Figure 4. 7: The complete lattice P(Sign) = (P(Sign), ~).
P(V) P(D)
oj/;:jo 'fJ
V D
Example 4.21 Let us consider the two complete lattices (P(Z), ~) and
(P(Sign), ~) where Sign = {-,O,+}; see Figure 4.7. The extraction function
sign : Z ---> Sign
simply defines the signs of the integers and is specified by:
- ifz<O
sign(z)= { O ifz=O
+ if z >o
The above construction then gives us a Galois connection
(P(Z), Gsign, 1'sign, P(Sign))
with
Gsign(Z) {sign(z) 1 z E Z}
1'sign(S) {z E Z 1 sign(z) E S}
where Z ~ Z and S ~ Sign. •

4.3.1 Properties of Galois Connections

We shall present three interesting results. The first result says that a Galois
connection is fully determined by either one of the abstraction and concreti-
sation functions:
Lemma 4.22 If (L, a,"(, M) is a Galois connection then:
(i) a uniquely determines 'Y by 'Y(m) = U{l 1 a(l) !;.;; m} and 'Y uniquely
determines a by a(l) = n{m Il!;.;; 'Y(m)}.
(ii) a is completely additive and 'Y is completely multiplicative.
In particular a(j_) = j_ and 'Y(T) = T. •

Proof To show (i) we shall first show that ris determined by a. Since (L, a,/, M)
is an adjunction by Proposition 4.20 we have r(m) = U{l 1 l ~ r(m)} = U{l 1
a( l) ~ m}. This shows that a uniquely determines 1: if both ( L, a, 11, M) and
(L,a,12,M) are Galois connection then 11(m) = U{ll a(l) ~ m} = 12(m) for ali
m and hence 11 = 12.
Similarly, we have a(l) = n{m 1 a(l) ~ m} = n{m Il ~ r(m)} and this shows
that r uniquely determines a.
To show (ii) consider L' ~ L; using Proposition 4.20 we then have
a(UL') ~ m {::} UL' ~ r(m)

{::} Vl EL' : l ~ r(m)
{::} Vl E L' : a(l) ~ m
{::} U{a(l) Il EL'}~ m
and it follows that a(U L') = U{ a(l) Il E L'}.

The proof that r(nM') = n{r(m) 1 m E M'} is analogous. •
Motivated by Lemma 4.22 we shall say that if (L, a,"(, M) is a Galois con-
nection then a is the lower adjoint (or left adjoint) of 'Y and that 'Y is the
upper adjoint (or right adjoint) of a.
The next result shows that it suffices to specify either a completely additive
abstraction function or a completely multiplicative concretisation function in
order to obtain a Galois connection:
Lemma 4.23 If a : L ---+ M is completely additive then there exists

'Y : M ---+ L such that (L, a,"(, M) is a Galois connection. Similarly, if
'Y : M ---+ L is completely multiplicative then there exists a : L ---+ M such
that (L, a,"(, M) is a Galois connection. •
Proof Consider the claim for a and define "( by:
'Y(m) = u{l' 1 a(l') [:;; m}
Then we have a(l) [:;; m =} l E {l' 1 a(l') [:;; m} =} l [:;; 'Y(m) where the last
implication follows from the definition of 'Y· For the other direction we first observe
that l [:;; 'Y(m) =} a(l) [:;; a('Y(m)) because a is completely additive and hence
monotone. Now
a("((m)) a(U{l' 1 a(l') [:;; m})
U{a(l') 1 a(l') [:;; m}

[:;; m
sol [:;; 'Y(m) =} a(l) [:;; m. It follows that (L, a,"(, M) is an adjunction and hence a
Galois connection by Proposition 4.20.
The proof of the claim for "( is analogous. •
The final result shows that we neither Iose nor gain precision by iterating
abstraction and concretisation:
Fact 4.24 If (L,a,"'f,M) is a Galois connection then a o "Y o a= a and

"'fOaO"'f ="'f· •
Proof We have >..l.l [:;; "(o a and since a is monotone we get a [:;; a o ('Y o a).
Similarly (a o 'Y) o a[:;; a follows from a o 'Y [:;; >..m.m. Thus a o 'Y o a= a.
The proof of 'Y o a o 'Y = "( is analogous. •
Example 4.25 As a somewhat more complex example consider the com-
plete lattices Interval= (Interval,~) and P(Sign) = (P(Sign), ~)of Fig-
ures 4.2 and 4.7, respectively.
Let us define a concretisation function "Yrs : P(Sign) ---+Interval by:
"YIS({-,0,+}) [-oo, oo] "Yrs({-,0}) [-oo,O]

"YIS({-,+}) [-oo, oo] "YIS( {o,+}) [O,oo]
'YIS ( {-}) [-oo, -1] "YIS({O}) [0,0]
"Yrs ({ +}) [l,oo] "YIS(0) ..l
To determine whether or not there exists an abstraction function
ars : Interval ---+ P(Sign)
such that (Interval, ars, 'Y!s, P(Sign)) is a Galois connection, we shall sim-
ply determine whether or not "Yrs is completely multiplicative: If it is, then
Lemma 4.23 guarantees that there does indeed exist a Galois connection and
Lemma 4.22 tells us how to construct the abstraction function. If "Yrs is
not completely multiplicative then Lemma 4.22 guarantees that there cannot
exist a Galois connection. In order to determine whether ar not 1'Is is com-
pletely multiplicative we shall use Lemma A.4 of Appendix A: It is immediate
ta verify that P(Sign) is finite and that 'Yrs satisfies conditions (i) and (ii)
of Lemma A.4. Ta verify condition (iii) we need ta compare 'Yrs(S1 n 82) ta
'Yrs(SI) n 'Yrs(S2) for all pairs (81. 82) E P(Sign) x P(Sign) of incomparable
sets of signs, i.e. all pairs in the following list:
({-,0},{-,+}), ({-,0},{0,+}), ({-,0},{+}),

({-,+},{0,+}), ({-,+},{0}), ({0,+},{-}),
({-},{0}), ({-},{+}), ({0},{+})
In checking the pair ({-, O}, {-, +}) we calculate
'Yrs ( {-, 0} n {-, +}) 'Yrs( {-}) [-oo, -1]

'/'IS ({-, 0}) n '/'rS ( {-, +}) [-oo, O] n [-oo, oo] [-oo,O]
and we deduce that 'Yrs is not completely multiplicative. Hence according

ta Lemma 4.22 we cannot find any ars : Interval --+ P(Sign) such that
(Interval, ars, 'Yrs, P(Sign)) is a Galois connection. •
The mundane approach to correctness. We shall now return

ta further motivating that the connection between L and M should be a
Galois connection. Recall from Section 4.1 that the semantic correctness of
an analysis may be expressed by a correctness relation R between the values
of V and the properties of L ar it may be expressed by a representation
function /3 mapping the values of V to their description in L. When we
replace L with some other complete lattice M we would obviously like the
correctness results still ta hold. We shall now see that if there is a Galois
connection (L, a,'/', M) between L and M then we can construct a correctness
relation between V and M and a representation function from V to M.
Let us first focus an the correctness relation. So let R : V x L --+ { true, false}
bea correctness relation that satisfies the conditions (4.4) and (4.5) of Section
4.1. Further let (L, a,'/', M) be a Galois connection between the complete
lattices L and M. It is then natural ta define S: V x M--+ { true,false} by
v S m iff v R ('Y(m))
and we shall now argue that this is a correctness relation between V and M
fulfilling conditions corresponding ta (4.4) and (4.5). We have
(v S mi) A m1 ~ m2 ::::} v R ('Y(m1)) A 'Y(ml) ~ 'Y(m2)

::::} v R ('Y(m2))
::::} V 8 m2
using that 'Y is monotone and that R satisfies condition (4.4); this shows that
S also satisfies condition (4.4). Also for all M' ~ M we have
(Vm E M': v S m) ::::} (Vm E M': v R ('Y(m)))
::::} vR(n{'Y(m)lmEM'})
* v R ('Y(nM'))
::::} v 8 (nM')
using that 'Y is completely multiplicative (Lemma 4.22) and that R satisfies
condition (4.5); this shows that S also satisfies condition (4.5). Hence S
defines a correctness relation between V and M.
Continuing the above line of reasoning assume now that R is generated by the
representationfunction {3: V-+ L, i.e. v R l {::} {3(v) ~ l. Since (L,a,"f,M)
is a Galois connection and hence an adjunction (Proposition 4.20) we may
calculate
v S m {::} R ('Y(m))
v
{::} {3(v) ~ 'Y(m)
{::} (a o {3)(v) ~ m
showing that S is generated by a o {3 : V -+ M. This shows how the Galois
connection facilitates the definition of correctness relations and representa-
tion functions and concludes our motivation for why it is natural to require
that the connection between L and M is specified by a Galois connection.
4.3.2 Galois Insertions

For a Galois connection (L, a, "f, M) there may be several elements of M that
describe the same element of L, i.e. 'Y need not be injective, and this means
that M may contain elements that are not relevant for the approximation of
L.
The concept of Galois insertion is intended to rectify this: (L, a, "f, M) is a
Galois insertion between the complete lattices L = (L, ~) and M = (M, ~)
if and only if
a :L -+ M and 'Y : M -+ L are monotone functions
that satisfy:
ao'Y >..m.m
Thus we now require that we do not Iose precision by first doing a concretisa-
tion and then an abstraction. As a consequence M cannot contain elements
Figure 4.8: The Galois insertion (L,a,"(,M).
that do not describe elements of L, i.e. M does not contain superfluous ele-
ments.
Example 4.26 The calculations of Example 4.19 show that

(P(Z), aZI, 'YZI, Interval)
is indeed a Galois insertion: we start with an interval, use 'YZI to determine

the set of integers it describes and next use azi to determine the smallest
interval containing this set and we get exactly the same interval as we started
with. •
The concept of a Galois insertion is illustrated in Figure 4.8 and is further

clarified by:
Lemma 4.27 For a Galois connection (L, a,"(, M) the following claims
are equivalent:
(i) (L, a,"(, M) is a Galois insertion;
(ii) a is surjective: '1/m E M : :Jl E L : a(l) = m;
(iii) "( is injective: 'l/m1,m2 E M: "f(m!) = "f(m2)::::} m1 = m2; and
(iv) 'Y is an order-similarity: 'l/m1. m 2 E M :
'Y(m!) !;;;; 'Y(m2) {::} m1 !;;;; m2. •
Proof First we prove that (i) => (iii). For this we calculate
where the last step follows from (i).

Next we prove that (iii) ~ (ii). FormE M we have -y(o:(y(m)) = -y(m) by Fact
4.24 and hence a('Y(m)) = m by (iii).
Now we prove that (ii) ~ (iv). That m1 [:;:; m2 ~ -y(m1) [:;:; -y(m2) is immediate
since 'Y is monotone. Next suppose that -y(m1) [:;:; -y(m 2); by monotonicity of a this
gives a('Y(m1)) [:;:; a('Y(m2)); using (ii) we can write m1 = a(h) and m2 = a(b) for
some l1, l2 E L; using Fact 4.24 this then gives m 1 [:;:; m 2 as desired.
Finally we prove that (iv) ~ (i). For this we calculate
a('Y(m1)) [:;:; m2 <(=} -y(m1) [:;:; -y(m2) <(=} m1 [:;:; m2
where the first step is using Proposition 4.20 and the last step is using (iv). This
shows that a('Y(m1)) and m1 have the same upper bounds and hence are equal. •
Lemma 4.27 has an interesting consequence for a Galois connection given by

an extraction function TJ : V --+ D: it is a Galois insertion if and only if TJ is
surjective.
Example 4.28 Consider the complete lattices (P(Z), ~) and (P(Sign x

Parity),~) where Sign = {-,0,+} as before and Parity = {odd,even}.
Define the extraction function signparity : Z --+ Sign x Parity by:
. . ( z ) = { (sign(z), odd) if zis odd

s1gnpanty .
(s1gn(z), even) if zis even
This gives rise to a Galois connection (P(Z), O:signparity, 'Ysignparity, P(Sign X

Parity)). The property (0, odd) describes no integers so clearly signparity is
not surjective and we have an example of a Galois connection that is not a
Galois insertion. •
Construction of Galois insertions. Given a Galois connection

(L, o:,')', M) it is always possible to obtain a Galois insertion by enforcing
that the concretisation function 'Y is injective. Basically, this amounts to
removing elements from the complete lattice M using a reduction operator
c.;:M--+M
defined from the Galois connection. We have the following result:
Proposition 4.29
Let (L, o:, -y, M) be a Galois connection and define the reduction
operator c.; : M --+ M by
c.;(m) = n{m' 1 -y(m) = -y(m')}

Then c.;[M] = ({c.;(m) m E M},[:;;M) is a complete lattice and
1
(L, o:, -y, c.;[M]) is a Galois insertion.

Figure 4.9: The reduction operator~: M--+ M.
This is illustrated in Figure 4.9: The idea is that two elements of M are
identified by ~ if they map to the same value by ')'; in particular, m and
a('Y(m)) will be identified.
In preparation for the proof we shall first show the following two results:
Fact 4.30 Let (L, a,')', M) be a Galois connection. Then

a[L] = ({a(l) \lE L}, !;;;;M)
is a complete lattice. •
Proof Clearly o:[L]
~ M is partially ordered by the ordering l;;:M of M = (M, l;;:M ).
We now want to show for M' ~ o:[L] ~ M that
We first show that UM M' E o:[L] which means that there exists l EL such that
a(l) = UM M'. For this take l = UL 'Y[M'] which clearly exists in L. Since
a o 'Y o a = a (Fact 4.24) and a is completely additive (Lemma 4.22) we then have
a(l) o:(UL 'Y[M'])

UMo:['Y[M']]
UMM'
thus showing UM M' E o:[L]. Since UM M' is the least upper bound of M' in M
it follows that it also is in o:[L]. By Lemma A.2 we then have the result. •
Fact 4.31 If (L, a,')', M) is a Galois connection and

~(m) =n{m' 1 'Y(m') = 'Y(m)}
then
~(m) = o{y(m))
and hence a[L) = ~[M).
•
Proof We have <;(m) ~ a(-y(m)) because -y(m) = -y(o:('Y(m))) using Fact 4.24.
That o:('Y(m)) ~ ~,;(m) is equivalent to -y(m) ~ -y(<;(m)) using Proposition 4.20 and
-y(~,;(m)) = nb(m') 1 -y(m') = -y(m)} = -y(m) follows from Lemma 4.22.
Next consider o:(l) for l E L; by Fact 4.24 we have o:(l) = o:(-y(o:(l))) and hence
o:(l) = ~,;(o:(l)); this shows o:[L] ~ ~,;[M]. Finally consider ~,;(m) for m E M; then
~,;(m) = o:('Y(m)); this shows ~,;[M] ~ o:[L]. •
We now turn to the proof of Proposition 4.29:

Proof Facts 4.30 and 4.31 give that ~,;[M] = o:[L] is a complete lattice. Since
(L,o:,-y,M) is an adjunction (Proposition 4.20) it follows that also (L,o:,-y,o:[L])
is. Since o: is surjective on o:[L] it follows from Lemma 4.27 that we have a Galois
insertion. •
Reduction operators defined by extraction functions. We
shall now specialise the construction of Proposition 4.29 to the setting where
a Galois connection (P(V), a.","(.", P(D)) is given by an extraction function
rJ : V ---+ D. Then the reduction operator ~." is given by
~."(D') = D' n ry[V)

wherery[V) = {ry(v) 1 vE V}denotestheimageofryandfurthermore~."[P(D))
is isomorphic (see Appendix A) to P(ry[V]) (see Exercise 4.14). The result-
ing Galois insertion will therefore be isomorphic to (P(V), a.","(.", P(ry[V])):
Formally, the Galois connection (L 1 , a1, 'Yb M 1 ) is isomorphic to the Ga-
lois connection (L2, a2, "(2, M2) when there are isomorphisms (h : L 1 ---+ L 2
and ()M : M1 ---+ M2 (see Appendix A) such that a2 = ()M o a1 o 0"L 1 and
'Y2 = eL o 'Y1 o o;}.
Example 4.32 Returning to Example 4.28 we can use the above tech-
nique to construct a Galois insertion. Now
signparity[Z) = {( -, odd), (-, even), (0, even), (+, odd), (+, even)}
showing that (P(Z), asignparity, 'Ysignparity, P(signparity[Z))) is the resulting Ga-
lois insertion. •
4.4 Systematic Design of Galois Connections

Sequential composition. When developing a program analysis it is
often useful to do so in stages: The starting point will typically be a com-
plete lattice (Lo, ~) fairly closely related to the semantics; an example is
4.4 Systematic Design of Galois Connections 247
(P(V), ~). We may then decide to use a more approximate set of prop-
erties and introduce the complete lattice (Lt, ~) related to L 0 by a Galois
connection (Lo, 0:1, 1'1, Lt). This step can then be repeated any number of
times: We replace one complete lattice Li of properties with a more ap-
proximate complete lattice (Li+l, ~) related to Li by a Galois connection
(Li, ai+ 1, 'Yi+ 1, Li+ t). This process will stop when we have an analysis with
the required computational properties. So the situation can be depicted as
follows:
-
'Yk
The above sequence of approximations of the analysis could as well have been
done in one step, i.e. the "functional composition" of two Galois connections
is also a Galois connection. Formally, if (Lo, 0:1, 1'1. L1) and (L1, 0:2, '/'2, L2)
are Galois connections, then
is also a Galois connection. To verify this we simply observe that o: 2(o: 1(1 0 )) ~
12 <=? o:1(1o) ~ 1'2(12) <=? 1o ~ 'Y1b2(12)) and, using Proposition 4.20, this
shows the result. A similar result holds for Galois insertions because the
functional composition of surjective functions yields a surjective function.
Each of the Galois connections (Li, ai+ 1, 'Yi+ 1, Li+ 1) may have been obtained
by combining other Galois connections and we shall shortly introduce a num-
ber of techniques for doing so. We shall illustrate these techniques in a se-
quence of examples that in the end will give us a finite complete lattice that
has turned out tobe very useful in practice for performing an Array Bound
Ana1ysis.
Example 4.33 One of the components in the Array Bound Analysis is

concerned with approximating the difference in magnitude between two num-
bers (typically the bound and the index). We shall proceed in two stages:
First we shall approximate pairs (z1, z2) of integers by their difference in
magnitude lz1l-lz2l and next we shall further approximate this difference
using a finite lattice. The two Galois connections will be defined by extrac-
tion functions and they will then be combined by taking their functional
composition.
The first stage is specified by the Galois connection
(P(Z X Z),o:diff,'/'diff,P(Z))
where diff: Z x Z ~ Z is the extraction function calculating the difference

in magnitude:
The abstraction and concretisation functions O:diff and 1'diff will then be
o:d;rr(ZZ) {lz1l-lz2l 1 (z1, z2) E ZZ}

1'dirr(Z) = {(z1, z2) 1 lz1l-lz2l E Z}
for ZZ ~ Z x Z and Z ~ Z.
The second stage is specified by the Galois connection
(P(Z), O:range, 1'range, P(Range))
where Range = {<-1,-1,0,+1,>+1}. The extraction function range: Z-+

Range clarifies the meaning of the elements of Range:
<-1 if z < -1
-1 if z = -1
range(z) = o if z =o
+1 if z =1
>+1 if z>1
The abstraction and concretisation functions O:range and 1'range will then be
O:range(Z) {range(z) 1 z E Z}
1'range(R) = {z 1 range(z) E R}
for Z ~ Z and R ~ Range.

We then have that the functional composition
(P(Z x Z),o:R,1'R, P(Range))
where O:R = O:range o O:diff and 1'R = 1'diff o 1'range, is a Galois connection. We
obtain the following formulae for the abstraction and concretisation functions:
{range(lz1l-lz21) 1 (z1, z2) E ZZ}

{(z1, z2) 1 range(lz1l-lz2l) E R}
Using Exercise 4.15 we see that this is the Galois connection specified by the
extraction function range o diff : Z x Z -+ Range. •
A catalogue of combination techniques. We have seen that the

"functional (or sequential) composition" of Galois connections gives rise to
a new Galois connection. It is also useful to be able to do "parallel com-
binations" and this will be the topic for the remainder of this section. We
may have analyses for the individual components of a composite structure
and may want to combine them into an analysis for the whole structure; we
shall see two techniques for that: the independent attribute method and the
relational method. We shall also show how Galois connections can be used
to approximate the total function spaces and the monotone function spaces.
Alternatively, we may have several analyses of the same structure and may
want to combine them into one analysis and here the direct product and the
direct tensor product allow us to do that. Using the notion of Galois inser-
tions this leads to a study of the reduced product and the reduced tensor
product.
The benefit of having such a catalogue of techniques is that a relative small
set of "basic" analyses, whose correctness have been established, can be used
to construct rather sophisticated analyses and, from an implementation point
of view, opens up the possibility of reusing existing implementations. Finally,
it is worth stressing that the complete lattices used in program analysis ob-
viously can be constructed without using these techniques but that it often
provides additional insights to view them as combinations of simpler Galois
connections.
4.4.1 Component-wise Combinations

The first techniques we shall consider are applicable when we have several
analyses of individual components of a structure and we want to combine
them into a single analysis.
Independent attribute method. Let (Ll,at,')'1,M1) and (L 2,a 2,

')'2, M2) be Galois connections. The independent attribute method will then
give rise to a Galois connection
where:
a(h,b) (a1(h), a2(l2))

1(m1, m2) (1'1 (m1), 'Y2(m2))
To see that this indeed does define a Galois connection we simply calculate
a(h,l2) ~ (m1,m2) <=? (a1(h),a2(l2)) ~ (mt,m2)

<=? a1(h)~m1 1\ a2(l2)~m2
<=? h ~'Yl (m1) 1\ l2 ~ 'Y2(m2)
<=? (h,l2) ~ ('Y1(m1),')'2(m2))
<=? (h, l2) ~ 1(m1, m2)
and use Proposition 4.20. A similar result holds for Galois insertions (Exercise
4.17).
Example 4.34 The Array Bound Analysis will contain a component that
performs a Detection of Signs Analysis on pairs of integers. As a starting
point, we take the Galois connection
(P(Z), Gsign, 'Ysign, P(Sign))

specified by the extraction function sign in Example 4.21. It can be used
to analyse both components of a pair of integers so using the independent
attribute method we will get a Galois connection
(P(Z) x P(Z), ass, ')'ss, P(Sign) x P(Sign))

where ass and ')'ss are given by
ass(Zl, Z2) ({sign(z) 1 z E Z1},{sign(z) 1 z E Z2})

'Yss(Sl. S2) = ({z 1 sign(z) E Sl},{z 1 sign(z) E S2})
where Zi ~ Z and Si ~ Sign.

This Galois connection cannot be described using an extraction function be-
cause neither P(Z) x P(Z) nor P(Sign) x P(Sign) is a powerset. However,
they are both isomorphic to powersets:
P(Z) x P(Z) ~ P( {1, 2} x Z)
P(Sign) x P(Sign) ~ P( {1, 2} x Sign)
By defining the extraction function twosigns : {1, 2} x Z ~ {1, 2} x Sign
using the formula twosigns(i, z) = (i, sign(z)) we obtain a Galois connection
(P({1,2} X Z),atwosigns,'Ytwosigns,P({1,2} X Sign))

that is isomorphic to (P(Z) x P(Z), ass, ')'ss, P(Sign) x P(Sign)).
In general the independent attribute method often leads to imprecision. An
expression like (x,-x) in the source language may have a value in {(z, -z) 1
z E Z} but in the present setting where we use P(Z) x P(Z) to represent sets
of pairs of integers we cannot do better than representing {(z, -z) 1 z E Z}
by (Z, Z) and hence the best property describing it in the analysis of Example
4.34 will be ass(Z, Z) = ( {-,O,+}, {-,O,+}). Thus we Iose ali information
about the relative signs of the two components. •
Relational method. In the independent attribute method there is ab-

solutely no interplay between the two pairs of abstraction and concretisation
functions. It is possible to do better by allowing the two components of the
analysis to interact with one another so as to get more precise descriptions.
Let (P(Vl), a1, ')'1, P(D1)) and (P(V2), a2, ')'2, P(D2)) be Galois connections.
The relational method will give rise to the Galois connection
where
a(VV) U{a1({v1}) x a2({v2}) 1 (v1,v2) E VV}

'Y(DD) {(v1,v2) a1({v1}) x a2({v2})
1 ~ DD}
where vv ~ vl X v2 and DD ~ Dl X D2. Let us check that this does indeed

define a Galois connection. From the definition it is immediate that a is
completely additive and hence that there exists a Galois connection (Lemma
4.23). It remains to show that 'Y (as defined above) is the upper adjoint of
a. For this we can use Lemma 4.22 and calculate
'Y(DD) {(v1,v2) 1 a1({vl}) x a2({v2}) ~ DD}

{(v1,v2) a({(v1,v2)}) ~ DD}
1
U{VVI a(VV) ~ DD}
where one way of proving the equality is to use that a is completely additive.
This shows the required result.
It is instructive to see how the relational method is simplified if the Galois
connections (P(Vi), ai, '/i, P(Di)) are given by extraction functions 'T/i :Vi----+
Di, i.e. if ai(~')= {TJi(vi) 1 Vi E ~'} and 'Yi(DD ={vi 1 TJi(vi) E D;}. We
then have
a(VV) { ('T/1 (vi), 'T/2 (v2)) v1, v2) E VV}

1 (
'Y(DD) {(v1,v2) 1 (ryl(vl),ry2(v2)) E DD}
which also can be obtained directly from the extraction function TJ : V1 X V2 ----+
D1 x D2 defined by ry(v1,v2) = (ryi(vi),ry2(v2)).
Example 4.35 Let us return to Example 4.34 and show how the rela-
tional method can be used to construct a more precise analysis. We will now
get a Galois connection
(P(Z x Z),ass','YSS', P(Sign x Sign))
where ass' and 'YSS' are given by
ass'(ZZ) {(sign(z1), sign(z2)) 1 (z1, z2) E ZZ}

'YSS' (SS) {(z1, z2) 1 (sign(zl), sign(z2)) E SS}
where ZZ ~ Z x Z and SS ~ Sign X Sign. This corresponds to using an ex-

traction function twosigns' : Z x Z ----+ Sign x Sign given by twosigns' (z1, z2 ) =
(sign(zl), sign(z2)).
Once again consider the expression (x, -x) in the source language that has
a value in {(z, -z) 1 z E Z}. In the present setting {(z, -z) \ z E Z} is an
element ofP(Z x Z) and it is described by the set ass,({(z, -z) 1 z E Z}) =

{(-,+),(0,0),(+,-)} of P(Sign x Sign). Hence the information about the
relative signs of the two components is preserved. This will be the Galois
connection that we will use in our further development of the Array Bound
Analysis. •
The above treatment of the relational method can be extended in a very

general way. Let us write P(V1 )®P(V2 ) for P(V1 x V2 ) and similarly P(DI)®
P(D2) for P(D 1 x D2). It is possible to perform a more general development
using a notion of tensor product for which L 1 ® L 2 exists even when the
complete lattices L 1 and L 2 are not powersets. We refer to the Concluding
Remarks for information about this.
Total function space. In Appendix A it is established that if L is a

complete lattice then so is the total function space S---+ L for S being a set.
We have a similar result for Galois connections:
Let (L, a,/, M) be a Galois connection and let S bea set. Then we obtain
a Galois connection
(S---+ L, a', 1', S---+ M)
by taking
a'(!) a of
r' (g) 'o g
To see this we first observe that a' and 1' are monotone functions because a
and 1 are; furthermore
r' (a'(!))
a'(r'(g))
follow since (L, a,/, M) is a Galois connection. A similar result holds for
Galois insertions. The construction is illustrated by the following commuting
diagrams:
L M L M
~~)
s s
Example 4.36 Assume that we have some analysis mapping the program
variables to properties from the complete lattice L, i.e. operating on the ab-
stract states Var ---+ L. Given a Galois connection (L, a,"(, M) the above
construction will show us how the abstract states of Var ---+ L are approxi-
mated by the abstract states of Var---+ M. •
Monotone function space. In Appendix A it is established that the

monotone function space between two complete lattices is a complete lattice.
We have a similar result for Galois connections:
Let (L1, a1, "/1, Ml) and (L2, a2, "/2, M2) be Galois connections. Then we
obtain the Galois connection
by taking
a(!) a2 o f o 'Yl
"f(g) "/2 o g o a1
To check this we first observe that the functions a and 'Y are monotone
because a2 and "/2 are; next we calculate
'Y(a(f)) ("/2 o a2) of o ("/1 o al) ::::J f

a('Y(g)) ( a2 o 'Y2) o g o (a1 o 'Yl) C g
using the monotonicity of f: L1 ---+ L2 and g: M1---+ M2 together with (4.8)

and (4.9). A similar result holds for Galois insertions (Exercise 4.17).
This construction is illustrated by the following commuting diagrams:
f "f(g)
L1 L2 L1 L2
>I 1 j a, a1 j ]~
M1 M2 M1 M2
a(!) g
4.4.2 Other Combinations

So far our constructions have shown how to combine Galois connections deal-
ing with individual components of the data into Galois connections dealing
with composite data. We shall now show how two analyses dealing with the
same data can be combined into one analysis; this amounts to performing two
analyses in parallel. We shall consider two variants of this analysis, one "cor-
responding" to the independent attribute method and one "corresponding"
to the relational method.
Direct product. Let (L,a1,1'I,Ml) and (L,a 2,1'2,M2) be Galois con-

nections. The direct product of the two Galois connections will be the Galois
connection
where a and 1' are given by:
(al (l), a2(l))

1'1(m1) n1'2(m2)
To see that this indeed defines a Galois connection we calculate
a(l)!:::; (m1, m2) {::} a1(l)!:::; m1 1\ a2(l)!:::; m2

{::} l !:::; 1'1 (m 1) 1\ l !:::; 1'2 (m2)
{::} l!:::; 1'(m1,m2)
and then use Proposition 4.20 to get the result.
Example 4.37 Let us consider how this construction can be used to com-
bine the detection of signs analysis for pairs of integers given in Example 4.35
with the analysis of difference in magnitude given in Example 4.33. We get
the Galois connection
(P(Z x Z), assR, 1'ssR, P(Sign x Sign) x P(Range))
where assR and 1'SSR are given by:
assR(ZZ) ({(sign(zi), sign(z2)) (z1, z2) E ZZ},

1
{range(lz1l-lz2l) 1 (z1, z2) E ZZ})

1'SSR(SS, R) {(z1, z2) 1 (sign(z1), sign(z2)) E SS}
n{(z1, z2) 1 range(lz1l-lz2l) E R}
Note that the expression (x, 3*x) in the source language has a value in
{(z,3*z) 1 z E Z} which is described by assR({(z,3*z) 1 z E Z}) =
({(-,-),(0,0),(+,+)},{0,<-1}). Thus we do not exploit the fact that ifthe
pair is described by (o, O) then the difference in magnitude will indeed be
described by O whereas if the pair is described by (-, -) or (+, +) then the
difference in magnitude will indeed be described by <-1. •
Direct tensor product. In the direct product there is no interplay

between the two abstraction functions and as we saw above this gives rise
to the same loss of precision as in the independent attribute method. It
is possible to do better by letting the two components interact with one
another. Again we shall only consider the simple case of powersets so let
(P(V),ai,1'i, P(Di)) be Galois connections. Then the direct tensor product
is the Galois connection
where a and 1' are defined by:
a (V') U{a1({v}) x a2({v}) 1 vE V'}

1'(DD) {v 1 a1({v}) x a2({v}) ~ DD}
where V' ~ V and DD ~ D 1 x D 2 . To verify that this defines a Galois

connection we calculate
a(V') ~ DD 9 't:/v E V': a1({v}) x a2({v}) ~ DD

9 't:/v E V' : v E 1'(DD)
9 V' ~ 1'(DD)
and then use Proposition 4.20.

The construction can be simplified if the two Galois connections (P(V), ai,
1'i, P(Di)) are given by extraction functions 'f)i : V ----> Di, i.e. if ai(V') =
{TJi(v) 1 VE V'} and 1'i(DD = {v 1 TJi(v) Eva. Then we have
a (V') {(TJI(v),TJ2(v)) 1 vE V'}

1'(DD) {v 1 (TJI(v),TJ2(v)) E DD}
which also can be obtained directly from the extraction function 'f) : V ---->
D 1 x D 2 defined by TJ(v) = (TJI(v),TJ2(v)).
Example 4.38 Let us return to Example 4.37 and show how the direct
tensor product gives a more precise analysis. We will now get a Galois con-
nection
(P(Z x Z),assR',1'SSR', P(Sign x Sign x Range))
where
assR'(ZZ) {(sign(z!), sign(z2), range(lz1l-lz21)) 1 (z1, z2) E ZZ}

1'SSR' ( SSR) {(z1, z2) (sign(z!), sign(z2), range(lz1l-lz2l)) E SSR}
1
for ZZ <:;:: Z x Z and SSR <:;:: Sign x Sign x Range.

It is worth pointing out that this Galois connection is also obtainable from
the extraction function
twosignsrange: Z x Z --t Sign x Sign x Range
defined by twosignsrange(z1, z2) = (sign(z1), sign(z2), range(lz1l-lz21)).
Returning to the precision of the analysis we will now have assR' ({ (z, 3 * z) 1
z E Z}) = {(-,-,<-1),(0,0,0),(+,+,<-1)} and hence have a more precise
description than in Example 4.37.
However, it is worth noticing that the above Galois connection is not a Ga-
lois insertion. To see this consider the two elements 0 and {(O, O, <-1)} of
P(Sign x Sign x Range) and observe that
')'SSR' (0) = 0 = ')'SSR' ( {(0, 0, <-1)})
Thus 'YSSR' is not injective and hence Lemma 4.27 shows that we do not have
a Galois insertion. •
Reduced product and reduced tensor product. The con-

struction of Proposition 4.29 gives us a general method for turning a Galois
connection into a Galois insertion. This technique can now be combined
with the other techniques for combining Galois connections and this is of
particular interest for the direct product and the direct tensor product.
Let (L, a 1, ')'1, Ml) and (L, a2, ')'2, M2) be Galois connections. Then the re-
duced product is the Galois insertion
(L, a, -y, c;[M1 x M2])
where
a(l) (a1(l), a2(l))
-y(m1,m2) 'Yl(ml) n-y2(m2)
c;(m1,m2) n{(m~, m~) 1 'Y1(m1) n 'Y2(m2) = 'Yl(mD n ')'2(m~)}
To see that this is indeed a Galois insertion recall that we already know
that the direct product (L, a,')', M1 x M2) is a Galois connection and that
Proposition 4.29 then shows that (L, a,')', c;[M1 x M2]) is a Galois insertion.
Next let (P(V), ai, 'Yi, P(Di)) be Galois connections for i = 1, 2. Then the
reduced tensor product is the Galois insertion
where
a(V') U{a1({v}) x a2({v}) 1 vE V'}
-y(DD) {v 1 a1({v}) x a2({v}) ~ DD}
c;(DD) n{DD' 1 -y(DD) = -y(DD')}
Again it follows from Proposition 4.29 that this is indeed a Galois insertion.
Example 4.39 Let us return to Example 4.38 where we noted that the
complete lattice P(Sign x Sign x Range) contains more than one element
that describes the empty set of P(Z x Z). The superfluous elements will
be removed by the construction of Proposition 4.29. The function (SSR' will
amount to
<;ssR'(SSR) = n{SSR' 'YssR'(SSR)

1 = 'YSSR'(SSR')}
where SSR, SSR' <:;;; Sign x Sign x Range. In particular, <;ssR' will map the
singleton sets constructed from the 16 elements
(-,o, <-1), (-,0,-1), (-,0,0),

(o,-,o), (o,-, +1), (o,-, >+1),
(o, o, <-1), (0,0,-1), (o, o, +1), (o, o, >+1),
(o,+, o), (o,+, +1), (0, +, >+1),
(+,0,<-1), (+,o, -1), (+,o, o)
to the empty set. The remaining 29 elements of Sign x Sign x Range are
(- - <-1) (- - -1) (-,-,o), ( -, -, +1), (-, -, >+1),

' '
(-,o, +1),
' ' ' '
(-,o, >+1),
(-,+,<-1), (-,+,-1), (-,+,o), (-,+,+1), (-,+,>+1),
(o,-, <-1), (o,-, -1), (0,0,0), (o,+, <-1), (0,+,-1),
(+, -, <-1), (+, -, -1), (+, -, 0), (+, -, +1), (+, -, >+1),
(+,o, +1), (+,o, >+1),
(+, +, <-1), (+, +, -1), (+,+,o), (+,+,+1), (+,+,>+1)
and they describe disjoint subsets of Z x Z. Let us call the above set of 29
elements for AB (for Array Bound); then <;ssR' [P(Sign x Sign x Range)] is
isomorphic to P(AB).
To conclude the development of the complete lattice and the associated Ga-
lois connection for the Array Bound Analysis we shall simply construct the
reduced tensor product of the Galois connections of Examples 4.35 and 4.33.
This will yield a Galois insertion isomorphic to
(P(Z x Z), o:ssR', 'YssR', P(AB))
Note that from an implementation point of view the last step of the con-
struction has paid off: if we had stopped with the direct tensor product in
Example 4.38 then the properties would need 45 bits for their representation
whereas now 29 bits suffice.
Summary. The Array Bound Analysis has been designed from three simple
Galois connections specified by extraction functions:
(i) an analysis approximating integers by their sign (Example 4.21),
(ii) an analysis approximating pairs of integers by their difference in mag-

nitude (Example 4.33), and
(iii) an analysis approximating integers by their closeness to O, 1 and -1

(Example 4.33).
We have illustrated different ways of combining these analyses:
(iv) the relational product of analysis (i) with itself,
(v) the functional composition of analysis (ii) and (iii), and
(vi) the reduced tensor product of analysis (iv) and (v).
It is worth noting that because the resulting complete lattice P(AB) is a

powerset then it is indeed possible to obtain the very same Galois insertion
using an extraction function twosignsrange': Z x Z--+ AB. •
4.5 Induced Operations

We shall now show that Galois connections are indeed useful for transforming
computations into more approximate computations that have better time,
space, or termination behaviour. We can do so in two different ways. In both
cases we assume that we have an analysis using the complete lattice L and
that we have a Galois connection (L, a.,"(, M).
One possibility is to replace the analysis using L with an analysis using M.
In Subsection 4.5.1 we shall show that if the analysis using M is an upper
approximation to the analysis induced from L then the correctness properties
are preserved. We shall illustrate this approach in Subsection 4.5.2 for the
Monotone Frameworks considered in Chapter 2.
An alternative is only to use the complete lattice M for approximating the
fixed point computations in L. So rather than performing all computations
on the more approximate lattice M the idea is only to use M to ensure con-
vergence of fixed point computations and not needlessly reduce the precision
of all other operations. We shall illustrate this in Subsection 4.5.3.
4.5.1 lnducing along the Abstraction Function

Now suppose that we have Galois connections (Li, ai, "fi, Mi) such that each
Mi is a more approximate version of Li (for i = 1, 2). One way to make use
4.5 lnduced Operations 259
of this is to replace an existing analysis /p : L1 --+ L2 with a new and more

approximate analysis gp: M1 --+ M2. We already saw in Section 4.4 that
0:2 o /p o 'Yl is a candidate for gp
(just as 'Y2 o 9p o 0:1 would bea candidate for fp)· The analysis 0:2 o /p o 'Yl is
said to be induced by fp and the two Galois connections. This is illustrated
by the diagram:
/p
Lt L2
~' 1 la,
Mt M2
0:2 o /p o 'Yl
Example 4.40 Let us return to Example 4.9 where we studied the simple
program plus and specified the very precise analysis
/plus(ZZ) = {zl + Z2 1 (z1, z2) E ZZ}
using the complete lattices (P(Z), ~) and (P(Z x Z), ~). In Example 4.21
we introduced the Galois connection
(P(Z), O:sign, 'Ysign, P(Sign))
for approximating sets of integers by sets of signs. In Example 4.35 we used
the relational method to get the Galois connection
(P(Z x Z), o:sS', 'YSS', P(Sign x Sign))
operating on pairs of integers. We now want to induce a more approximate
analysis for the plus program
9plus : P(Sign X Sign) --+ P(Sign)
from the existing analysis /plus· To do so we take
9plus = O:sign O /plus O 'YSS 1
and simply calculate (for SS ~ Sign x Sign)

9plus (SS) O:sign (!plus bss' (SS)))
O:sign(/plus({(zt,Z2) E Z X Z 1 (sign(zt),sign(z2)) E SS}))
O:sign({zt +z2l Zt,Z2 E Z,(sign(zt),sign(z2)) E SS})
{sign(z1 + z2) 1 Zt, z2 E Z, (sign(zt), sign(z2)) E SS}
U{s1 EB s2 1 (s1, s2) E SS}
where EB : Sign x Sign--+ P(Sign) is the "addition" operator on signs (so
e.g. + EB + = {+} and + EB- = {-,0,+}). •
The mundane approach to correctness. We shall now follow

the approach of Section 4.1 and show that correctness of fp carries over to
gp. For this assume that:
Ri : Vi x Li ---+ { true, false} is generated by f3i : Vi ---+ Li
The correctness of the analysis /p : L1 ---+ L2 is then expressed by
where R1 - R2 is generated by f3l - fJ2 (Lemma 4.8). As argued in Section

4.3 we get a correctness relation Si for Vi and Mi by letting
si : Vi X Mi ---+ { true, false} be generated by ai o f3i : Vi ---+ Mi
which is equivalent to saying that Vi Si mi<=> ViRi ('Yi(mi)). The correctness

relation for the analysis using M 1 and M2 will be S1 - S 2 which will be
generated by (al o (31) - (a2 o (32) (Lemma 4.8). We now have the following
useful result:
Lemma 4.41 If (Li, ai, '/'i, Mi) are Galois connections, and f3i : Vi ---+Li
are representation functions then
holds for all -vt.

•
Proof To see this we simply calculate
u{ 0:2(,82(v2)) 1 O:I (,BI (vl)) !;;;; mi 1\ VI "'-'+ V2}
a2(U{.B2(v2) I.BI(vi)!;;;; /I(mi) 1\ VI,..__.. v2})

a2 ( (.BI-.82)("'-'+ )( /I (mi)))
and the result follows. •

We shall now show that Lemma 4.41 yields:
This just means that if /p is correct and if gp is an upper approximation to

the induced analysis then also gp is correct. So suppose that
and that a2 o fpo'/'l ~ gp. Since (Li, ai, '/'i, Mi) are Galois connections and fv
and gp are monotone we get fv ~ 1'2 o gp o a1 as illustrated in the diagrams:
4.5 Induced Operations 261
fp fp
Ll L2 L1 L2
1' 1 l
1n
a2 a, j
1n
11'
M1 M2 M1 M2
gp gp
It follows that ((31 ---* (32 ) (p f- · '"'0 ·) l;;:; 12 o gp o a1 and hence
a2 o (/31 ---* fJ2) (p f- · '"'0 ·) o "11 l;;:; 9p
By Lemma 4.41 this is the desired result.

We shall say that a function JP : L1 --+ L2 is optimal for the program p if
and only if correctness of a function f' : L1 --+ L2 amounts to JP l;;:; f'. An
equivalent formulation is that JP is optimal if and only if
Lemma 4.41 may then be read as saying that if JP: L1 --+ L2 is optimal then
so is a2 o fp o 11 : M1 --+ M2.
Fixed points in the induced analysis. Let us next consider the

situation where the analysis JP : L 1 --+ L 2 requires the computation of the
least fixed point of a monotone function F : (L1 --+ L2) --+ (L1 --+ L2) so
that JP = lfp(F). The Galois connections (L;, a;,"(;, M;) give rise to a Galois
connection (L 1 --+ L2, a,"(, M 1 --+ M2) between the monotone function spaces
as shown in Section 4.4. We can now apply our technique of inducing and
let G : (M1 --+ M 2 ) --+ (M1 --+ M 2 ) be an upper approximation to a oF o T
It will be natural to take gp : M 1 --+ M 2 to be gp = lfp( G). That correctness
of fp carries over to gp follows from the following general result:
Lemma 4.42 Assume that (L, a,"(, M) is a Galois connection and let f:
L --+ L and g : M --+ M be monotone functions satisfying that g is an upper
approximation to the function induced by J, i.e.:
Then for all m E M:
g(m) l;;:; m:::} f('Y(m)) l;;:; 'Y(m)

and furthermore lfp(f) l;;:; 'Y(lfp(g)) and a(lfp(f)) l;;:; lfp(g).
•
Proof First assume g(m)!;;; m. The assumption a of o 7!;;; g gives o:(f('Y(m)))!;;;
g(m) and hence o:(f('Y(m)))!;;; m. Using that a Galois connection is an adjunction
(Proposition 4.20) we get f('Y(m)) 1:::: 7(m) as required.
To prove the second result we observe that {l(m) 1 g(m) ~ m} <;;; {l 1 f(!) ~ !}
follows from the previous result. Hence we get (using Lemma 4.22):
Using Tarski's Theorem (Proposition A.lO) twice we have lfp(g) = nRed(g) =

n{m 1 g(m) ~ m} and lfp(f) = nRed(f) = n{z 1 f(l) ~ l} so it follows that
)'(lfp(g)) :;:) lfp(f) as required. Then a(lfp(f)) ~ lfp(g) follows because a Galois
connection is an adjunction. •
4.5.2 Application to Data Flow Analysis

Generalised Monotone Frameworks. To illustrate how these
techniques can be applied we shall now consider a generalisation of the Mono-
tone Frameworks of Section 2.3. So let a generalised Monotone Framework
consist of:
• a complete lattice L = (L, ~).
Here we do not demand that L satisfies the Ascending Chain Condition and
we do not specify the space F of transfer functions as we shall be taking
F tobe the entire space of monotone functions from L to L (which clearly
contains the identity function and is closed under composition of functions).
An instance A of a generalised Monotone Framework then consists of:
• the complete lattice, L, of the framework;

• a finite flow, F <;;; Lab x Lab;
• a finite set of extremal labels, E <;;; Lab;
• an extremal value, LE L; and
• a mapping, J., from the labels Lab of F and E to monotone transfer
functions from L toL.
As in Chapter 2 this gives rise to a set A-;). of constraints

ifCEE
=:J U{A.(C') 1 (C',C) E F} u L~ where L~ = { ~ iUrf.E
A. (C) =:J fe (A a ( C))
where C ranges over the labels Lab of F and E. We write (Aa, A.) f= A-;).
whenever Ao, A. : Lab ----+ L is a solution to the constraints A-;;J.. It is useful
to consider the associated monotone function
[: (Lab ___, L) x (Lab ----+ L) ----+ (Lab ----+ L) x (Lab ----+ L)

defined by:
-
f(Ao,A.) = ( >.f. u {A.(f)t 1 (f t ,f) E F} U tE,
R >.f.JR(Ao(f)))
We then have the following important result (in the manner of Section 4.4):
(Ao,Ae);! f(A 0 ,A.) is equivalent to (Ao,Ae) r= A~

Galois connections and Monotone Frameworks. Let now
(L, a,"(, M) be a Galois connection and consider an instance B of the gener-
alised Monotone Framework M that satisfies
• the mapping g. from the labels Lab of F and E to monotone transfer

functions of M -+ M satisfies 9R ;! a o fR o "( for all f; and
• the extrema! value J satisfies J ;! a( t)
and otherwise B is as A, i.e. has the same F and E.

As above we get a set of constraints B~ and we write (Bo, B.) B~ when- r=
ever Bo, B. : Lab -+ M is a solution to the constraints. The alternative
formulation is (Bo, B.);! g(Bo, B.) where g: (Lab-+ M) X (Lab-+ M)-+
(Lab -+ M) x (Lab -+ M) is the monotone function associated with the
constraints.
We shall now see that whenever we have a solution to the constraints obtained
from B then we also have a solution to the constraints obtained from A. This
can be expressed by:
We can give a direct ("concrete") proof of this result but it is instructive to

see how it follows from the general ("abstract") results established earlier.
The idea is to "lift" the Galois connection (L, a,"(, M) to a Galois connection
( (Lab -+ L) x (Lab -+ L), a', "( 1, (Lab -+ M) x (Lab -+ M))
using the techniques for total function spaces and the independent attribute
method presented in Section 4.4. The assumptions 9R ;! a o fR o 'Y (for all f)
and J ;! a( t) can then be used to establish
g ;) a' o f o "( 1
as the following calculations show
(a' of o "f 1)(Bo, B.) = (>.f. U{a('Y(B.(f'))) 1(f',f) E F} U a(t~),

>.f.a(JR('Y(Bo (i)))))
c g(Bo,B.)
where we have used that o:(j_) = j__ We can now use Lemma 4.42 to obtain
g(Bo, B.) ~ (Bo, B.) implies fb'(Bo, B.)) ~ "/(Bo, B.)
and it follows that if (Bo, B.) f= B;:::J then ('y o Bo, "(o B.) f= A;:::J as stated
above.
The mundane approach to correctness. The above result shows

that any solution to the constraints obtained for B also is a solution to the
constraints obtained from A. We shall now show that semantic correctness of
A implies semantic correctness of B.
Let us reconsider the approach taken to semantic correctness in Section 4.1;
here F = Bow(S*) and E = {init(S*)}. For the analysis A this calls for using
a representation function
{3 : State --+ L
and the correctness of all solutions to A;:::J then amounts to the claim:
Assume that (Ao, A.) f= A;:::J and (S*, a1) --+* a2;
(4.11)
then {3(at) ~ ~ implies {3(a2) ~ U{A.(f) 1 f E final(S*)}.
For the analysis B it follows from Section 4.3 that it is natural to use the
representation function
o: o {3 : State --+ M
and the correctness of all solutions to B;:::J then amounts to the claim:
Assume that (Bo, B.) f= B;:::J and (S*, a1) --+* a2; (4 12 )
then (o: o {3)(at) ~ J implies (o: o {3)(a2) ~ U{B.(f) 1 f E final(S*)}. ·
We know that B is an upper approximation of the analysis induced from

A and shall now prove that (4.11) implies (4.12). To do so we shall need
to strengthen the relationship between the extremal values of A and B by
assuming that 1 satisfies
'Y(J) = ~
from which J;;;;) o:(~) readily follows. For the proof that (4.11) implies (4.12)
suppose that:
It follows that:
From (4.11) we get {3(a2) ~ Uh o B.(f) 1f E final(S*)} and hence {3(a2) ~

'Y(U{B.(f) 1 f E final(S*)}) showing the desired (o: o {3)(a2) ~ U{B.(f) 1 f E
final(S* )}.
A Worked Example
As a concrete example we shall now consider an analysis SS for the WHILE
language that approximates how sets of states are transformed into sets of
states. First we prove that it is correct. Then we show that the Constant
Propagation Analysis of Section 2.3 is an upper approximation of an analysis
induced from 55. This will then establish the correctness of the Constant
Propagation Analysis.
Sets of states analysis. The analysis SS approximating the sets of

states will be a generalised Monotone Framework with:
• the complete lattice (P(State), ~).
Given a labei consistent statement S* in Stmt we can now specify the in-
stance as follows:
• the flow F is fiow( S*);

• the setE of extremallabels is {init(S*)};
• the extremal value L is State; and
• the transfer functions are given by j 55 :
f[S(I;) { O"[X f--7 A[a]O"] 1 O" E I:} if [x := a]C is in s*

ffS(I;) I; if [skip]f is ins*
ffS (I:) I; if [b]R is in s*
where I; ~ State.
Correctness. The following result shows that this analysis is correct in

the sense explained above:
Lemma 4.43 Assume that (SSo, ss.) F 55 2 and (S*, 0"1) ---+* 0"2i then
State implies 0"2 E U{ ss. (.e) 1.e E final( s*)}.
0"1 E •
Proof From Section 2.2 we have:
(S, a-) -+ (S', a') implies final(S) :2 final(S') 1\ flow(S) :2 flow(S')
and as in Chapter 2 it is immediate that
flow(S) :2 flow(S') 1\ (SSo,SS.) 1= SS;;J(S) implies (SSo,SS.) 1= SS;;J(S')
It then suffices to show
(SSo,SS.) 1= SS;;J(S) 1\ (S,a)-+ a' 1\ a E SSo(init(S))
implies a' E U{ SS. (1!) 1! E final( S)}
1
(SSo,SS.) 1= SS;;J(S) 1\ (S,a)-+ (S',a') 1\ a E SSo(init(S))

implies a' E SSo(init(S'))
since then an induction on the length of the derivation sequence (S*, a1) ----+ * a 2 will
give the result. The proof proceeds by induction on the inference in the semantics.
We only consider a few of the interesting cases.
The case ([x := a]f, a) ----+ a[x ..... A[a]a]. Then 55;:2 (S) will contain the equation
SS.(f) :2 {a[x ..... A[a]a]l a E SSo(f)}
and since init([x :=an= f and final([x :=an= {f} we see that that the required
relationship holds: if a E SSo(f) then a[x ..... A[a]a] E SS.(f).
The case (S1; S2, a) ----+ (S~; S2, a') because (S1, a) ----+ (S~, a'). From the assumption
a E SSo(init(S1;S2)) we get a E SSo(init(Sl)) and the induction hypothesis gives
a' E SSo(init(SD). But then a' E SSo(init(S~; S2)) as required.
The case (S1;S2,a)--+ (S2,a') because (S1,a)--+ a'. From the assumption a E
SSo(init(S1; S2)) we get a E SSo(init(Sl)) and the induction hypothesis gives a' E
U{SS.(f) 1 f E finaJ(S1)}. We have
{(f,init(S2)) f E finaJ(S1)} <:;; flow(S1;S2)
1
and since we have the constraints
for all f we get

SSo(init(S2)) :2 U{SS.(f) f
1 E finaJ(Sl)}
and hen ce a' E SSo (init( S2)) as required.
The remaining cases follow the same pattern and are omitted. •
Remark. The SS analysis is unlikely to be optimal and hence is unlikely
to equal the collecting semantics (see Section 1.5 or Exercise 4.5). This may
be demonstrated by exhibiting an example where U{SS.(C) 1 CE finaJ(S*)}
is strictly larger than {a' (S*, a) -+* a' A a E State} and it is fairly easy
1
to do so. To obtain a specification of the collecting semantics we should let

transfer functions be associated with edges rather than nodes as this would
allow us to record the outcome of tests (see Exercise 2.11). •
Constant Propagation Analysis. The analysis of Section 2.3 is

specified by a generalised Monotone Framework consisting of
• the complete lattice Statecp =((Var-+ zT)J_, ~).
The instance for the statement S* is determined by
• the flow F is flow( S*);

• the setE of extremallabels is {init(S*)};
• the extrema! value i is >.x.T; and
• the transfer functions are given by the mapping JCP defined in Table
2.7.
4.5 lnduced Operations 267
Galois connection. The relationship between the two analyses is es-

tablished by defining the representation function
f3cp : State --+ Statecp
by f3cp(a) =a (as in Example 4.6). As in Section 4.3 this gives rise to a Galois
connection (P(State), acp, 'YCP, Statecp) where acp(~) = U{f3cp(a) 1 a E
~} and ')'cp(â') ={a f3cp(a) r;;;; â'}. One can now show that for alllabels C
1
ffP ;;;;J acp o JfS o 'YCP
as well as 'YCP(>.x.T) =State. Let us only consider the case where [x := a]c
occurs in s* and calculate
acp (/J5('YCP (â'))) acp ur (

{a 1 a r;;;; â'}))
acp( {a[x f--7 A[a]a]l a r;;;; â'})
U{ a[x f--7 A[ a] a] 1 a r;;;; â'}
C â'[x f--7 U{A[a]a 1 ar;;;; â'}]
c ffP(â')
and where the last step follows from U{A[a]a 1 a r;;;; â'} r;;;; Acp[a]â' which
can be proved by a straightforward structural induction on a.
Thus we conclude that CP is an upper approximation to the analysis induced
from SS by the Galois connection and hence it is correct.
4.5.3 Inducing along the Concretisation Function

Widening operator induced by Galois connection. Suppose
that we have a Galois connection (L, a, -y, M) between the complete lattices
L and M, and also a monotone function f : L --+ L. Often the motivation
for approximating f arises because a fixed point of f is desired, and the
ascending chain (r (l_) )n does not eventually stabilise (or may do so in too
many iterations). Instead of using o; of o-y: M --+ M to remedy this situation
it is often possible to consider a widening operator 'VM : M x M --+ M and
use it to define 'VL : L x L --+ L by the formula:
If 'VL turns out tobe a widening operator we then know how to approximate
the least fixed point of f : L --+ L while calculating over L. This has the
advantage that the coarser structure of M is only used to ensure convergence
and does not needlessly reduce the precision of all other operations. The
following result gives sufficient criteria for this approach to work:
Proposition 4.44
Let (L, a, 'Y, M) bea Galois connection and let 'VM : M x M--+ M
be an upper bound operator. Then the formula
defines an upper bound operator 'VL : L x L --+ L. It defines

a widening operator if one of the following two conditions are
fulfilled:
(i) M satisfies the Ascending Chain Condition, or
(ii) (L, a, 'Y, M) is a Galois insertion and 'VM : M x M --+ M is
a widening operator.
Proof First we prove that "\h is an upper bound operator. Since 'VM is an upper
bound operator we have a(l;) !;;;; o:(h)'VMo:(l2)· Using that a Galois connection is
an adjunction we get l; !;;;; 'Y(o:(h)'VMo:(l2)), i.e. l; !;;;; h '\1Ll2.
Assume now that condition ~i) is fuifilled and consider an ascending chain (ln)n
in L. We know that aiso (ln L )n is an ascending chain and that l;[L E 'Y[M] for
n > O. Hence (a(l;[L) )n is an ascending chain and since M satisfies the Ascending
Chain Condition there exists no ~ 1 such that a(l;[L) = a(l;[~) for all n ~ no. So
'Y(a(l;[L )) = 'Y(a(l;[~)) for ali n ~ no and using that 'Y o a o 'Y = 'Y (Fact 4.24) we
get l;[L = l;[~ for ali n ~ no. This compietes the proof.
Assume next that condition (ii) is fuifilled and consider again an ascending chain
(ln)n in L. Since a is monotone it follows that (a(ln)n) is an ascending chain in M.
Now, 'VM is a widening operator on M so there exists no such that (a(ln))vM =
(a(ln 0 ))vM for n ~ no. We shall now prove that
(a(ln))VM = a(l;[L) (4.13)
for all n ~O. The case n =O is immediate since (o:~lo))vM = a(lo) = a((ciL). For
the induction step we assume that (a(ln))vM = a(lnL). Then
(a(ln+l)) VM = (a(ln)) VM 'VM a(ln+l)
a(l;[L) 'VM a(ln+l)
and
a(l;[L \JL ln+I)
a('Y(a(l;[L) 'VM a(ln+l)))
a(l;[L) 'VM a(ln+I)
since (L, a, "f, M) is a Gaiois insertion.
Using (4.13) we thus have that there exists no such that a(l;;L) = a(z;;g) for all
n ~ n 0 • But then 'Y(a(l;[L)) = 'Y(a(l;[~)) and hence l;[L = l;[~ for all n ~ n 0 as
was shown above. This compietes the proof. •
Precision of induced widening operator. The following result

compares the precision of using the widening operator ''\h with the precision
of using the widening operator \lM.
Lemma 4.45 If (L, a,"(, M) is a Galois insertion such that 'Y(..l-M) = .lL,
and if \lM : M x M---+ M is a widening operator, then the widening operator
\IL : L x L - t L defined by h \IL l2 = 'Y(a(h) \lM a(l2)) satisfies
for all monotone functions f : L ---+ L. •

Proof By Proposition 4.44 we already know that "\h is a widening operator. Hence
there exists nf 2:: O such that lfp,_h (!) = J;~ = fvL for all n 2:: nf. Next write
g =a of o 'Y and recall that VM is a widening operator. Hence there exists n 9 2:: O
such that lfpvM (g) = g~~ = g'VM for all n 2:: n 9 • To obtain the desired result it
therefore suffices to prove
(4.14)
by induction on n. The base case (n = O) is immediate since f~L = _l_L and

g~M = _l_M and we assumed that _l_L = 'Y(_l_M ).
To prepare for the induction step we prove that (4.14) implies that:
(4.15)
For"~" we calculate (using (4.14) and that (L,a,"(,M) is a Galois connection):
f(fvL)!;;:; fvL ~ a(f(fvL))!;;:; a(fvL)

~ a(! ('Y(9VM))) !;;:; a('Y(9VM))
~ g(g'VM)!;;:; a('Y(g'VM))
~ g(gvL) !;;:; 9VM
For ".ţ=" we calculate (using (4.14) and that (L,a,"(,M) is a Galois connection):
g(g'VM)!;;:; 9VM ~ "f(g(gvM))!;;:; "f(9vM)

~ 'Y(a(f('Y(Y'VM)))) ~;;:; 'Y(Y'VM)
~ 'Y( aUUvL m~;;:; tvL
~ f(fvL) !;;:; fvL
Returning to the induction step (n >O) of the proof of (4.14) we calculate:
)
if g (YvM
n-1) C:: n-1
- YvM
otherwise
)
n-1
YvM if g(g~;}) [;:; g~-;}
g~-;} "iJM g(g~;}) otherwise
-y(g~M)
In this calculation we have used that (4.14) and (4.15) hold for n-1, the definition
of "ilL, and that (L, a, -y, M) is a Galois insertion. •
This result then provides the formal justification for the motivating remarks
in the beginning of the subsection. To be specific let M be of finite height,
let (L, a,"(, M) be a Galois insertion satisfying "f(.lM) = .lL, and let "ilM be
the least upper bound operator UM. Then the above lemma shows that
lfp._h (!) ="((lip( a of o"())
which means that Jfp.,h (!) equals the result we would have obtained if we
decided to work with a o f o 'Y : M ---+ M instead of the given f : L ---+ L;
furthermore the number of iterations needed turn out to be the same. Since
the greater precision of L over M is available for all other operations, this
suggests that the use of widening operators is often preferable to the approach
of Subsection 4.5.1.
Concluding Remarks
In this chapter we have only been able to touch upon a few of the central
concepts of Abstract Interpretation; this has mainly been based on [37, 39,
35, 40]. Mini Project 4.1 and the series of examples leading up to Example
4.39 are based on [179]. Mini Project 4.3 is inspired by [126, 68]. Much
more can be said both about the development of the theory and about its
applications. In this section we briefly discuss some of the more important
concepts that have been omitted so far.
Upper closure operators. An upper closure operator p : L---+ L is

a monotone function that is extensive (i.e. satisfies p ;;;) >.l.l) and idempotent
(i.e. p o p = p). Such operators arise naturally in Abstract Interpretation [39]
because whenever (L, a,"(, M) is a Galois connection the function "(o a : L ---+
L is easily seen to be an upper closure operator. Furthermore, if p : L ---+ L
is an upper closure operator then the image p[L] = {p(l) Il E L} of L under
p equals the set Fix(p) = {l E L 1 l = p(l)} of fixed points of p and is a
complete lattice under the partial ordering of L; in fact (L, p, >.l.l, p[L]) is a
Galois insertion.
It follows that upper closure operators may be used to represent Galois con-
nections by simply demanding that the more approximate space M is actually
a subset of L and that no essential features are lost by doing this. This then
opens up the possibility for directly comparing the precision of various Galois
connections over the same complete lattice L by simply relating the closure
operators. The reiat ion P1 !;;;; P2 is naturally defined by 't:/l E L : Pl (l) !;;;; P2 (l)
but turns out to be equivalent to the condition that p2 ( L) ~ p 1 ( L) and
represents the fact that P2 is more approximate than PI·
Having defined an ordering on the set of upper closure operators on L one
can next show that the set is a complete lattice: the least element is given
by the upper closure operator >-.l.l and the greatest element by >-.l. T. The
binary greatest lower bound operator n is of special interest: it gives rise to
the construction of the reduced product [39] (see Section 4.3.)
A number of additional constructs can be explained by means of upper clo-
sure operators: we just mention reduced cardinal power [39] and disjunctive
completion [39]. By "inverting" some of these constructions it may then be
possible to find the "optimal bases" with respect to a given combination: for
reduced product the notion of pseudo-complementation has been used to find
the minimal factors [33, 34], and for disjunctive complet ion one can identify
the basic irreducible properties that are inherently necessary for the analysis
[63, 64].
Stronger properties on the complete lattices. Being a com-

plete lattice is a rather weak notion compared to being a powerset. By
considering more structure on the complete lattices, say distributivity, and
identifying the elements that correspond to singletons, e.g. atoms or join irre-
ducible elements, it is frequently possible to lift some of the stronger results
that hold for powersets to a larger class of complete lattices.
Since powersets are isomorphic to bit vectors this gives a way of finding more
general conditions on analyses for when they are as efficient as the Bit Vector
Frameworks. This is of particular interest in the case of fixed points, where
one can use properties of distributive lattices and distributive analyses to
give rather low bounds on the number of iterations needed for the ascending
chain (r (l_) )n to stabilise [129, 118].
Another line of work concerns the development of the tensor product for
complete lattices that are not also powersets [111, 113, 115]. Severa! notions
of tensor product have been studied in lattice theory but the development of
tensor products suitable for program analysis was first done in [111].
Concrete analyses. In this chapter we have concentrated on introduc-

ing some of the key notions in the theory of Abstract Interpretation and only
occasionally have we hinted at concrete applications.
One of the main applications of Abstract Interpretation has been in the area
of logic programming. To implement a program efficiently it is important to
have precise information about the substitutions that may reach the various
program points; a central question to be asked for a substitution is whether or

not it is ground. A number of analyses have been designed for this and most
of these build upon the framework of Abstract lnterpretation. This includes
the design of iteration strategies based on widening, and the decomposition
of base domains using the techniques mentioned above under upper closure
operators.
Another main application of Abstract Interpretation has been to approxi-
mate subsets of n-dimensional vector spaces over integers or rationals. For
the purpose of this discussion we shall limit ourselves to at most two di-
mensions (the line and the plane). In the case of one dimension there are
two main techniques. One we already illustrated: the lattice of intervals,
and it may be generalised to consider (possibly finite) unions of intervals.
The other technique records sets of numbers modulo some base value, e.g.
{ x 1 x mod k 1 = k2}. Clear ly these two analyses can be combined. In the case
of two (or more) dimensions it is straightforward to perform an independent
attribute analysis where the techniques above are applied component-wise
for each dimension.
A substantial effort has been devoted to developing more interesting rela-
tional analyses for two (or more) dimensions where the choice of axes is of
less importance for the ability to approximate subsets of vector space. An
early method was the affine subspaces of Karr [94] where sets of the form
{(x,y) k1x + k2y = k3} can be described. The generalisation from equality
1
to inequality, and allowing to take intersections of such subsets, was consid-

ered by Cousot and Halbwachs [41] and resulted in a study of convex poly-
gons. Generalisations and combinations of these ideas have been developed
by Granger [66, 67] and by Masdupuy [105].
An interesting line of work pioneered by Deutsch [44, 45] is to change the
problem of describing regular sets of words over a finite alphabet to the
problem of describing sets of integer vectors. This is by no means trivial but
once it has been achieved it opens up the possibility for using all of the above
techniques to represent also regular sets of words. This is very important for
the analysis of higher-order and concurrent programs, as shown by Deutsch
and Colby [31, 32], since it can describe the shape of activation records and
communication patterns in much greater precision than other comparative
techniques.
We should also mention techniques for building the abstract space of prop-
erties "dynamically" [24] and for using widening and narrowing to improve
the performance of chaotic iteration [25].
Duality. The dual t;::;d of a partial ordering !;::; is obtained by defining

l 1 t;::;d l 2 if and only if l 2 !;::; h; thus we could write t;::;d as ~· Any concept
defined in terms of partial orderings can be dualised by replacing all partial
orderings by their dual. In this way the dual least element is the greatest
element, and the dualleast upper bound is the greatest lower bound etc. The
principle of lattice duality of Lattice Theory says that if any statement about
partially ordered sets is true then so is the dual statement. (Interestingly the
concept of monotonicity is its own dual.) However, we should like to point
out that the dual of a complete lattice may of course differ from the complete
lattice itself; pictorially we represent this by drawing the complete lattice
"up-side down".
The principle of lattice duality is important for program analysis because it
gives an easy way of relating the literature on Abstract Interpretation to the
"classical" literature on Data Flow Analysis: simply dualise the complete
lattices. So in Abstract Interpretation the greatest element is trivially safe
and conveys no information whereas in "classical" Data Flow Analysis it is
the least element that has this role. Similarly, in Abstract Interpretation we
are interested in least fixed points whereas in "classical" Data Flow Analysis
we are interested in greatest fixed points.
Staying within the basic approach of Abstract Interpretation, that going up
in the complete lattice means losing information, it is still possible to dualise
much of the development: in particular we can define the notion of dual Ca-
lois connections. To see why this may be worthwhile consider the following
scenario. In program analysis we aim at establishing an element le E L for
describing the set of values that may reach a given program point f. In pro-
gram transformation it is frequently the case that a certain transformation
3 is valid only if the set of values that reach a certain point have certain
properties; we may formulate this as the condition le ~ ls. Now if we want
to be more approximate we approximate le to l~ and ls to l~ and formulate
the approximate condition l~ ~ l~. To ensure that l~ ~ l~ implies le ~ ls we
demand that le ~ l~ and that l~ ~ ls. Thus properties of program points are
approximated by going up in the complete lattice, for which Galois connec-
tions are useful, whereas enabling conditions for program transformations are
approximated by going down in the complete lattice, and for this the concept
of dual Galois connections is useful.
A final word of advice concerns the interplay between Abstract Interpretation
and Denotational Semantics. In Denotational Semantics the least element
conveys absolutely no information, and we learn more when things get larger
according to the partial order; had there been a greatest element it would
have denoted conflicting information. This is quite opposite to the situation
in Abstract Interpretation where the greatest element conveys absolutely no
information and we learn more when things get smaller according to the par-
tial order; the least element often denotes non-reachability. Hence it would
be dangerous to simply apply too many of the intuitions from Denotational
Semantics when performing Abstract Interpretation not least because both
formalisms ask for least fixed points and therefore are not duals of one an-
other.
Mini Projects
Mini Project 4.1 A Galois Connection for Lists
In a series of examples leading up to Example 4.39 we constructed a Galois

insertion for recording the relationship between pairs of integers; it was given
by
(P(Z x Z),assR','/'SSR',P(AB))
where AB ~ Sign x Sign x Range contained only 29 elements (out of the
45 possi bili ties).
In this mini project we are going to construct a Galois insertion for recording
the relationship between pairs of lists. Let V be the domain of lists of finite
length over some simple data type. We write x = [xi, · · · , Xn] for a list with
n elements whose first element is xi; when n =O we write x = [ ]. Next let
x = [xi, · · ·, Xn] and y = [YI, · · · , Ym] be two lists. They have the same head
if and only if n > O, m > O and XI = YI· The list x is a suffix of y if and only
if there exists k 2 O such that n + k = m and Xi = Yi+k for i E {1, · · ·, n }.
Finally we write length(x) = n and length(y) = m.
The Galois insertion should have the form
(P(V x V), a, "f, P(LR))
where LR ~ P ({H, S}) x Range. Here H means that the lists have the same
head, S means that one list is a suffix of the other, and the range components
describe length(x)- length(y) where x is the first list and y the second list.
Complete the details of the specification. •
Mini Project 4.2 Correctness of the Shape Analysis
We shall now return to the Shape Analysis of Section 2.6 and show how it
gives rise to a Galois connection. Recall that the semantics uses configura-
tions with a state a E State and a heap component 1i E Heap and that the
analysis works on shape graphs consisting of an abstract state S, an abstract
heap H and a sharing component is.
We shall begin by defining a function vars that given a location and a state
will determine the associated abstract location:
vars(~)(a) = nx where X= {x 1a(x) =O

Proceed as follows:
1. Define a representation function

f3sA: State x Heap----> P(SG)
Mini Projects 275
that to each state and heap associates a singleton set consisting of a

compatible shape graph (as defined in Section 2.6) and construct the
associated Galois connection
(P(State x Heap), asA, )'sA, P(SG))
Is it a Galois insertion?
To establish the correctness of the analysis we shall follow the approach of

Subsection 4.5.2:
2. Specify an analysis SH approximating the sets of pairs of states and

heaps as a generalised Monotone Framework over the complete lat-
tice (P(State x Heap), ~); write JjH for the associated transfer func-
tions. Prove the correctness of the analysis SH (i.e. prove an analogue
of Lemma 4.43).
3. Show that JjA ;:;:) asA o JjH o )'SA for all transfer functions and conclude
that the Shape Analysis is correct. Determine whether or not JjA =
asA o JjH o )'SA holds for all transfer functions. (See Exercise 2.23.) •
Mini Project 4.3 Application to Control Flow Analysis
In this mini project we shall perform an analogue of the development of

Subsection 4.5.2 for the Control and Data Flow Analysis of Section 3.5.
1. Specify a "sets of values" analysis
(Csv, fisv) F=sv e

in the manner of Subsection 3.5.1 (by taking Data = Val where Val is
as in Section 3.2). Formulate and prove a semantic correctness result
in the manner of Example 4.40 and Theorem 3.10.
2. Let a monotone structure (L, :F) be given as in Subsection 3.5.2 and
consider a Galois connection (P(Val), a,)', L). Motivated by the judge-
ments of the acceptability relation (C, 6, p, d:) f= D e construct a Galois
connection:
({(Csv,fisv) l···},a',)'',{(C,6,p,d:) 1···})

Formulate and prove a result intended to establish
(C, 6, p, d:) f= D e =? )'1 ( (C, 6, p, d:)) f=sv e
and argue that this shows the semantic correctness of the Control and
Data Flow Analysis. •
O+
Figure 4.10: The complete lattice (Sign', ~).
Exercises
Exercise 4.1 For the complete lattice (Sign', ~) of Figure 4.10 definea
correctness relation RzS' : Z x Sign' - t { true, false}. Verify that it indeed has
the properties (4.4) and (4.5). Next define a representation function f3zS' :
Z - t Sign' and show that the Rzs' constructed above is indeed generated by
f3zS'. •
Exercise 4.2 Show that if (4.4) and (4.5) hold for R and L then we also
have:
and more generally:
(Vl E L' -~- 0 : v R l) ::::} V R (u L')
Give an example showing that v R ..l fails even though (4.4) and (4.5) are
fulfilled. •
Exercise 4.3 Show that the Control Flow Analysis of Chapter 3 is indeed
correct in the sense of condition (4.3) as claimed in Example 4.4. To do so
first show that
whenever vis a value (i.e. a closure ora constant). Next show that
is a corollary of Theorem 3.10. Finally assume the premise of (4.3) and use
the above results to obtain the desired result. •
Exercises 277
Exercise 4.4 Show that the relation RcFA defined in Example 4.4 is gen-
erated by the representation function f3cFA also defined in Example 4. 7. To
do so prove that
V RcFA (p, v) iff f3cFA (V) ~CFA (p, v)

by induction on the size of v; only the case where v is close t in p is non-
trivial. •
Exercise 4.5 Define Li = (P(Vi), ~) (for i = 1, 2) and define /p : L1 -+

L2 by
/p(h) = {v2 E V2 \ :Jv1 E h: p f-- Vt ~ v2}
Show that /p is monotone. Next show that (p f-- · ~ ·)(R1 ---.. R2) fp where
vi Ri li is defined by Vi E li. Also, show that for f' : L1 -+ L2 we have
(p f-- · ~ ·)(R1 ---.. R2) f' if and only if /p ~ f'. A semantics that associates a
program p with /p as defined here is sometimes called a collecting semantics.
Finally, note that Ri is generated by f3i defined by f3i (Vi) = {Vi}; show that
/p = ((31 ____.. fJ2)(p f-- • ~ ·). •
Exercise 4.6 Show that all of

• u
• .X(h,h).T
h ifh~h
• .X(h, 12). {
T otherwise
if h = .l
if 12 ~ h 1\ h -1- .l
otherwise
• .X(l l ). { h U h if h ~~'V l2 ~ h
1' 2 T otherw1se
are upper bound operators (where l' is some element of L). Determine which
of them that are also widening operators. Try to find sufficient conditions on
l' such that the operator involving l' is a widening operator. •
Exercise 4. 7 Show that if L satisfies the Ascending Chain Condition then

an operator on L is a widening operator if and only if it is an upper bound
operator. Conclude that if L satisfies the Ascending Chain Condition then
the least upper bound operator U: L x L-+ Lis a widening operator. •
Exercise 4.8 Consider changing the definition of J% from J% = .l to

!% = la for some la E L. Possible assumptions on la are:
• la = f(l-);
• la = P 7 ( .l);
• la E Ext(f);
• la arbitrary.
Which of these suffice for proving Fact 4.14 and Proposition 4.13? •
Exercise 4.9 Let 'h be as in Example 4.15 and define

int1 U int2 if int1 r:;;, int! V int2 r:;;, int1
{
int1 \lK int2 otherwise
where int! is an interval satisfying inf( int!) > -oo and sup( int!) < oo. Show
that
\:lint1, int2 : int1 \1 int2 r:;;, int1 \lK int2
and that the inequality may be strict. Show that \1 is an upper bound
operator. Determine whether or not \1 is a widening operator. •
Exercise 4.10 Let (ln)n bea descending chain and let ~ : L x L-+ L be
a total function that satisfies l~ r:;;, l~ =? l~ r:;;, (l~ ~ l~) r:;;, l~ for alll~, l~ E L.
Show that the sequence (l:; )n is a descending chain and that l:; ;;;) ln for all
n. •
Exercise 4.11 Consider the following alternative strategy to narrowing
for improving the approximation fv
E Red(f) to the fixed point lfp(f) of
the function f : L -+ L. A descending chain truncator is a function Y that
maps descending chains (ln)n to a non-negative number such that
if (ln)n and (l~)n are descending chains and \:In:::; Y((ln)n): ln = l~

then Y((ln)n) = Y((l~)n).
This ensures that Y is finitely calculable. The truncated descending chain

then is
UW, · · ·, rUW), · · ·, Jm' UV'))
where m' = Y((r(JW))n) and the desired approximation to lfp(f) is
Prove that this development can be used as an alternative to narrowing and

try to determine the relationship between the two concepts. •
Exercises 279
Exercise 4.12 Show that if L satisfies the Descending Chain Condition

then the binary greatest lower bound operator n : L x L - t L is a narrowing
operator. •
Exercise 4.13 Consider the complete lattice Interval of Figure 4.2 and
the complete lattice Sign' of Figure 4.10 and define 'YIS' by
'/'IS' (T) [-oo, oo] '/'IS' (-0) = [-oo,O]
'YIS' (0+) [O,oo] '/'IS' (-) [-oo, -1]
'/'IS' (0) [0,0] '/'IS' (+) [1,oo]
'/'IS' (J_) .l
Show that there exists a Galois connection between Interval and Sign' with
')'IS' as the upper adjoint. •
Exercise 4.14 Let (P(V), a 17 , ')'17 , P(D)) be a Galois connection that is

given by an extraction function "1 : V - t D. Show that a 17 is surjective if and
only if "1 is. Conclude that (P(V),a 17 ,')''1J, P(D)) is a Galois insertion if and
only if "1 is surjective. Next show that ~'IJ[P(D)] = a'IJ[P(V)] is isomorphic
(see Appendix A) to P(ry[V]) where ry[V] is the image of "1 and finally verify
that ~'IJ(V') =V' n ry[V]. •
Exercise 4.15 Assume that the Galois connections (P(Di), a'IJ;+p 'Y'IJi+P
P(Di+l)) are given by the extraction functions "li+l : Di - t Di+l· Show that
the composition of the Galois connections, (P(Do), o:,')', P(D2)), will have
a = a'IJ2 o am = a'IJ2 om and 'Y = 'Y'IJ 1 o ')'172 = 'Y'IJ2 o'IJ 1 ; i.e. the Galois connection
is given by the extraction function ry2 o ry 1. •
Exercise 4.16 Let (P(VI), a1, 'YI. P(DI)) and (P(V2), a 2, ')'2, P(D2)) be
Galois connections given by the extraction functions ry1 : V1 - t D 1 and ry2 :
V2 - t D2. Furthermore assume that V1 and V2 are disjoint and similarly for
D1 and D2. Define an extraction function
by
(v) = { "71 (V) if V E V1
"1 "72(v) ifv E V2
Show that this defines a Galois connection
and reformulate it as an isomorphic Galois connection
in the manner of the independent attribute method. How important is it

that Vi and V2 are disjoint and that D1 and D2 are disjoint? •
Exercise 4.17 Let (LI,ai,'/'I,MI) and (L2,a2,')'2,M2) be Galois inser-

tions. First define
a(h,l2) (a1(h),a2(h))
')'(mi, m2) ('/'1 (mI), '/'2 (m2))
and show that (L1 x L2, a,')', M1 x M2) is a Galois insertion. Then define
a(!) a2 o f o 1'1
1'(9) 1'2 o g o al
and show that (L1 -+ L2, a,')', M 1 -+ M 2) is a Galois insertion. •

Exercise 4.18 Let (P(VI),ai,')'I,P(DI)) and (P(V2),a2,')'2,P(D2)) be
Galois insertions. Define
a(VV) U{ai({vi}) x a2({v2}) (v1,v2) E VV}

1
"f(DD) {(VI, v2) a1 ({v1}) x a2 ({v2})

1 <:;:; D D}
and determine whether or not (P(VI x V2), a,')', P(D1 x D2)) is a Galois
insertion.
•
Exercise 4.19 Let (L, a 1 m, MI) and (L, a 2 ,')'2 , M 2 ) be Galois insertions.
Define
(ai(l), a2(l))
'/'I(ml) n')'2(m2)
and determine whether or not (L, a,')', M 1 x M 2 ) is a Galois insertion. •
Exercise 4.20 Let (LI,ai,')'I,MI) bea Galois connection and define
a(!) a1 o f o '/'1
')'(g) '/'l og oa1
(in the manner of Section 4.4). Do any of the following equalities
a(>.l.l) >.m.m
a(JI o h) a(JI) o a(h)
necessarily hold? Which of the equalities hold when (L1, a1, 1'1, M1) is known
to be a Galois insertion? •
Exercises 281
Exercise 4.21 Consider the Galois insertion

(P(Z x Z),o:ssR',')'SsR',P(AB))
developed in Example 4.39. Determine for each of the sets
{(x,y)lx=y}
{(x,y) 1 x = -y}
{(x,y) 1 x = y+ 1}
{(x,y) lx=y+3}
{(x,y) 1 x ~ y}
{(x,y) lx~y+1}
{(x, y) 1 x 2 + y2 :S 100}
the best description in P(AB). •

Exercise 4.22 Let (Li, ai, 'Yi, Mi) be Galois connections for i = 1, 2, 3.
Use the approach of Section 4.4 to define
o:(!)
'Y(g)
such that ((L1 x L2)--+ L3, o:,')', (M1 x M2)--+ M3) is a Galois connection.
Next let all of (Li, ai, ')'i, Mi) be the Galois connection
(P (Z), o:zr, ')'zr, Interval)

of Example 4.19 that relates the set of integers to the intervals. Let plus :
P(Z) x P(Z) --+ P(Z) be the "pointwise" application of addition defined by:
A(Zl, Z2).{zl + Z2 1 Zl E zl 1\ Z2 E Z2}
Next define
o:(plus) = A(int1, in~).···
and supply the details of the definition. •
Exercise 4.23 Let L be the complete lattice of sets of integers, let M
be the complete lattice of intervals of Example 4.10, let (L, a,')', M) be the
Galois insertion of Example 4.19, and let 'VM : M x M--+ M be the widening
operator of Example 4.15. Observe that the formula
defines a widening operator 'VL : L x L--+ L and developa formula for it (in
the manner of the formula for 'VM of Example 4.15). •
Exercise 4.24 Suppose that (L, a, 'Y, M) is a Galois connection ora Ca-
lois insertion and that possibly M satisfies the Descending Chain Condition.
Let f:l.M : M x M--+ M bea narrowing operator and try to determine if the
formula
defines a narrowing operator f:l.L : L x L--+ L. •

Chapter 5
Type and Effect Systems
So far our techniques have applied equally well to typed and untyped pro-
gramming languages. This flexibility does not apply to the development to
be performed in this chapter: here we demand that our programming lan-
guage is typed because we will use the syntax for types in order to express the
program analysis properties of interest (as was already illustrated in Section
1.6).
We shall first present an Annotated Type System for Control Flow Analy-
sis in Section 5.1, demonstrate its semantic soundness and other theoretical
properties in Section 5.2, and then in Section 5.3 show how to obtain an
algorithm for computing the annotated types (and prove that it is sound and
complete). In Sections 5.4 and 5.5 we give examples of other analyses spec-
ified by Type and Effect Systems. In Section 5.4 we study Type and Effect
Systems with rules for subtyping, polymorphism and polymorphic recursion
and illustrate their use in an analysis for tracking Side Effects, an Exception
Analysis and an analysis for Region Inference. Finally, in Section 5.5 we show
that the annotations can be given more structure and we illustrate this for a
Communication Analysis.
5.1 Control Flow Analysis

Syntax of the FUN language. To illustrate the approach we shall
make use of the functional language FUN also considered in Chapter 3; that
the approach also applies to the imperative language of Chapter 2 was briefly
sketched in Section 1.6. However, in this chapter we shall use a slightly
different labelling scheme from the one in Chapter 3; the syntactic category
of interest is
e E Exp expressions
284 5 Type and Effect Systems
and it is defined by:
e .. - c 1 x 1 fn'lr x => eo 1 fun1r f

x => eo 1 e1 e2
i f eo then e1 else e2 llet x = e1 in e2 1 e1 op e2
The program points, 1r E Pnt, are used to name the function abstractions in
the program; this could also be done using the notion of labelled terms from
Chapter 3 but for our present purposes we do not need the full generality
of this machinery - the reason is that now we will use the types to record
information that was previously associated with labels. Hence our syntax
just makes use of expressions and dispenses with terms.
As in the previous chapters we shall assume that a countable set of variables
is given and that constants (including the truth values), binary operators
(including the natural arithmetic, boolean and relational operators) and pro-
gram points are left unspecified:
c E Const constants
op E Op binary operators
J,x E Var variables
7r E Pnt program points
Example 5.1 The functional program (fn x => x) (fn y => y) con-
sidered in Chapters 1 and 3 is now written as
(fnx x => x) (fnv y => y)
just as we did in Example 1.5. •

Example 5.2 The expression loop of Example 3.2 is now written:
let g = (funF f x => f (fnv y => y))
in g (fnz z => z)
Recall that this is a looping program: g is first applied to the identity function
fnz z => z but it ignores its argument and calls itself recursively with the
function fnv y => y. •
5.1.1 The Underlying Type System

The analyses will be specified as extensions of the ordinary type system in
order to record the program properties of interest. For this reason the or-
dinary type system is sometimes called the underlying type system and we
shall start by specifying it.
5.1 Control Flow Analysis 285
[con] r f-uL C: Te
[var] r f-uL X : T ifr(x)=T
r[x ~--> Tx] f-uL eo : To

[fn]
r f-uL fn7r X => eo : Tx ---t To
r[j 1--> Tx ---t To][X 1--> Tx] f-uL eo : TQ

lfun]
r f-uL fun1r f X => eo : Tx ---t To
r f-uL e1 : T2 ---t To r f-uL e2 : T2

[app]
r f-uL e1 e2 : To
r f-uL eo : bool r f-uL e1 : T r f-uL e2 : T

[i~
r f-uL if eo then e1 else e2 : T
r f-uL e1 : T1 r[x 1--> T1] f-uL e2 : T2

[let]
r f-uL let X = e1 in e2 : T2
r f-uL e1 : T~p r f-uL e2 : T;p

[op]
r f-uL e1 Op e2 : Top
Table 5.1: The Underlying Type System.
Types. Let us first introduce the notions of types and type environments:
T E Type types
r E TEnv type environments
We shall assume that the types are given by
T ::= int 1 bool 1 T1 ---t T2
where int and bool are the only two kinds of base types and as usual we
use arrows for function types. Each constant c E Const has a type that we
shall denote Te so e.g. true has type Ttrue = bool and 7 has type T 7 = int.
Each binary operator op will expect two arguments of type T~P and T;P,
respectively, and give a result of type Top - an example is the relational
operation ~ that expects two arguments of type int and gives a result of
type bool. For the sake of simplicity we shall assume that all the constants
have base types and that all binary operators expect arguments of base types
and return values of base types.
The type environments are given by:
r ::= [li r[x ....... T]

Formally, r is a list but nevertheless we shall feel free to regard it as a finite

mapping: we write dom(r) for {x 1 r contains [x f--t • • ·]}; we write r(x) = 7
if x E dom(f) and the rightmost occurrence of [x f--t • • ·] in r is [x f--t 7],
and we write r 1 X for the type environment obtained from r by removing
all occurrences of [x f--t • • ·] with x i X. For the sake of readability we shall
write [x f--t 7] for [ ][x f--t 7].
Typing judgements. The general form of a typing is given by

f f-uL e: 7
that says that the expression e has type 7 assuming that any free variable
has type given by r. The axioms and rules for the judgements are listed in
Table 5.1 and are explained below.
The axioms [con] and [var] are straightforward: the first uses the predefined
type for the constant and the second consults the type environment. In the
rules [fn] and [!un] we guess a type for the bound variables and determine
the types of the bodies under the additional assumptions; the rule [!un] has
the implicit requirement that the guess of the type for f matches that of the
resulting function. As a consequence of these two rules the type system is
nondeterministic in the sense that f f-uL e : 71 and f f-uL e : 72 does not
necessarily imply that 71 = 72.
The rule [app] requires that the operator and the operand of the application
can be typed and implicitly it requires that the type of the operator is a
function type where the type before the arrow equals that of the operand
- in this way we express that the types of the formal and actual parameter
must be equal.
The rules [i~, [let] and [op] are straightforward. In particular, the let-
construct let x = e1 in e2 admits exactly the same typings as the application
(fn71" x => e2 ) e 1 and regardless of the choice of 1r. In Sections 5.4 and 5.5
we shall consider a polymorphic let-construct where let x = e 1 in e2 may
admit more typings than (fn1r x => e2) e1.
Example 5.3 Let us show that the expression loop

in g (fnz z => z)
of Example 5.2 has type 7 ~ 7 for each type 7. We shall first consider the
expression funF f X => f (fny y => y) where we write ffx for the type
environment [f f--t (7 ~ 7) ~ (7 ~ 7)][x f--t 7 ~ 7]. Then we get
ffx f-uL f : (7 ~ 7) ~ (7 ~ 7)
ffx f-uL fny y => y: 7 ~ 7
using the axiom [var] and the rule [Jn]. The rule [app] then gives
rfx f-uL f (fny y => y) : 7---* 7
and we have a judgement matching the premise of the rule [!un]. Hence we
get
[] f-uL fUllf f X=> f (fny y => y): (7---* 7)---* (7---* 7)
Taking r g to be the type environment [g f---> ( 7 ---* 7) ---* (7 ---* 7)] we get
rg f-uLg (fnz Z => z): 7---* 7
using the axiom [var] and the rules [Jn] and [app]. The rule [let] can now be
used to show that the expression loop has type 7---* 7. •
5.1.2 The Analysis

Annotated types. That a function has type 71 ---* 72 means that given
an argument of type 71 it will return a value of type 72 in case it terminates.
To get a Control Flow Analysis we shall annotate the type with information,
cp E Ann, about which function it might be. The annotations are given by
cp E Ann annotations
where:
cp ::= {rr} 1'Pl U 'P2 10
So cp will be a set of function names - describing the set of function definitions
that can result in a function of a given type; as will be discussed below, we
shall feel free to write {1r1, ... , 1fn} for {1r1} U · · · U {1fn}. We now take
7 E Type annotated types

r E TEnv- annotated type environments
and define:
7 .. - int 1bool 17l ~ 72
r
~
.... _ []1 Î'[xf---->7]
We shall write l7 J for the underlying type corresponding to the annotated
type 7; it is defined as follows:
lintJ int
lboolJ bool
l71 lfd ---* l72J
~ <p ~J
---t 72
As an example we have lint ~ intJ = (int---* int). Furthermore, we

extend the notation to operate on type environments so lfJ(x) = lf(x)J for
all x.
[con] r f-cFA C : Te
[var] r f-cFA X: T ifr(x)=7
[fn]
r f-cFA fn7r X => ea : Tx {7r }Ucp Ta
r[J f---+ Tx ~ ro] [x f---+ Tx] f-cFA ea : To

[!un]
r f-cFA fUILn- f X => ea : Tx ~ Ta
f f-cFA e1 : T2 _!:4 Ta f f-cFA e2 : 72

[app]
f f-cFA e1 e2 : Ta
r f-cFA ea : bool r f-cFA el : T r f-cFA e2 : T

[i~
r f-cFA i f ea then el else e2 : T
r f-cFA el : Tl r[x f---+ 71] f-cFA e2 : 72

[let]
f f-cFA let X = e1 in e2 : T2
1 2
r r
~ ~
f-cFA e1 : T 0 p f-cFA e2 : T 0 p
[op]
r f-cFA e1 Op e2 : Top
Table 5.2: Control Flow Analysis.
Judgements. The judgements of the Control Flow Analysis have the

form
r f-cFA e: T
and are defined by the axioms and rules of Table 5.2. The clauses [fn] and [!un]
annotate the arrow of the resulting function type with the information that
the abstraction named 1r should be included in the set of possible functions;
the use of {1r} U <p indicates that we may want to include other names as well
and we shall say that the Type and Effect System allows subeffecting (see
the Concluding Remarks). In Example 5.5 below we shall give an example
where subeffecting is indeed needed to analyse the expression. The remaining
clauses of Table 5.2 are straightforward modifications of the similar clauses
of Table 5.1.
Example 5.4 Let us return to the expression

(fnx x => x) (fny y => y)
of Example 5.1. Writing 7'v for int ~ int we have the following inference
tree:
[x f-t JY] f-cFA X ; JY [y f-t int] f-cFA y : int
[ ] f-cFA fnx X => X : JY ~ JY [ ] f-cFA fnv y => y : 7Y
[] f-cFA (fnx x => x) (fnv y => y) : 7'v

Note that the whole inference tree is needed to get full information about the
control flow properties of the expression. If we labei ali the subexpressions
as in Chapter 3 then we can list the types of the subexpressions as follows
and we are close to the information supplied by Cin Chapter 3. The infor-
mation corresponding to p can be obtained by "merging" information from
the various type environments of the inference tree (see Exercise 5.4). •
Example 5.5 Consider once again the expression loop

in g (fnz z => z)
and let us write ffx for [f f-t (T ~ 7') .J.t4 (T ~ 7')][x f-t 7' ~ 7'].
Using the clause [fn] we have
~ ~ {Y,Z}
rfx f-cFA fny y => y : T ---+ T
where we exploit that subeffecting allows us to enlarge the annotation from

the minimal {Y} to {Y, Z}. Using this we can construct an inference tree for:
[ l f-cFA funF f X => f (fny y => y ) : ( T~ {Y,Z} ~) {F}

- - - + T ---+
(~ 0
T ~ T
~)
Next let Î'g be [g f-t (T ~ 7') .J.t4 (7' ~ 7')]. We now exploit that the
annotation {Z} can be enlarged to {Z, Y} in the clause [fn] so that:
~ ~ {Z,Y} ~
r g f-cFA fnz Z => Z : T ---+ T
Since {Z, Y} = {Y, Z} we can use the clause [app] and get
~rg f-cFA g fnz ( Z => Z

)~0~
: T ~ T
[unit] rp=rpU0 [idem] rp=rpUrp
[com] 'Pl u 'P2 = 'P2 u 'Pl [ass] 'Pl u (rp2 u 'P3) = (rpl u 'P2) u 'P3
[re/] rp=rp
'Pl = rpi 'P2 = rp2

[trans] 'Pl = 'P2 'P2 = 'P3 [cong]
'Pl = 'P3 'Pl u 'P2 = rpi u rp2
Table 5.3: Equality of Annotations.
and eventually [ ] f-cFA loop : r L r. This can be interpreted as saying

that the expression loop does not terminate: the type is L but the r r
annotation 0 indicates that there will be no function abstractions with the
given type.
Actually we can show
[ l f-cFA funF f X => f (fny y => y ) : ( ~ {Y,Z}
T -t
~) {F} (~ cp ~)
T - t T --+ T
for every annotation rp and hence we have [ ] f-cFA loop : ~ for every r r
annotation rp; clearly the judgement with rp = 0 is the most informative. •
Equivalence of annotations. There are a few subtleties involved

in using this simple-minded system for Control Flow Analysis. One is the
r
implicit decision to regard a type like ~ ras being equal {Z,Y} 7. tor
Concerning this subtlety, we already explained that we feel free to write
{1r1>· · ·, 7rn} for {1r1} U · · · U {7rn}· Tobe utterly formal we should really say
that we write {1r1, ... , 7rn} for ((0 U {1r!}) U · · ·) U {7rn}·
Next we allow to replace T1 ~ T2 by T1 ~ T2 whenever 'Pl and rp2 are
"equal as sets" . To be utterly formal this can be axiomatised by the axioms
and rules of Table 5.3: the axioms [unit], [idem], [com] and [ass] express that
set union has a unit and is idempotent, commutative and associative, and the
axioms and rules [trans], [re~ and [cong] ensure that equality is an equivalence
relation as well as a congruence.
Finally, we allow to replace r1 by r2 if they have the same underlying types
and all annotations on corresponding function arrows are "equal as sets". To
be utterly formal we could axiomatise this by:
_, - 1
'Tl = 'T1 'T2 = T2 rp = rp
~
(Tl ~ 72) = (7'{ ~ ~)

It is customary to be informal about these fine technical points. But to
avoid confusion one should at the very least point out that annotations are
considered equal modulo the existence of a unit, commutativity, associativity,

and idempotence; the abbreviation UCAl is often used for this.
Conservative extension. Another subtlety is the ability to give the

abstraction fnv y => y the type r ~ r. Suppose for a moment that the
two rules for function abstraction did not have a {1r} U cp annotation on the
function arrows but only a {1r}. Then fnv y => y would have type ~ r r
but not ~r r;consequently the program from Example 5.5 would have
no type in the Annotated Type System for Control Flow Analysis! This is a
very undesirable property: we ought to be able to analyse ali programs.
To ensure that our system does not have the above deficiency we shall for-
mally prove that the Control Flow Analysis of Table 5.2 is a conservative
extension of the underlying type system of Table 5.1. This is expressed by:
Fact 5.6
(i) Iff f-cFA e: rthen LÎ'J f-uL e: LrJ.
(ii) If r f-uL e : T then there exists f and r such that
f f-cFA e : 7, LÎ'J = r and LTJ = T. •
Proof The proof of (i) is straightforward. For the proof of (ii) one annotates ali
arrows with the set of ali program points in e. •
This result paves the way for extending L·J to operate on entire typings:
applied to the typing f f-cFA e : rit produces a typing of the form LÎ'J f-uL
e : LTJ. As an example, the typing of Example 5.5 is transformed into the
typing of Example 5.3 (assuming that LrJ = r).
In Section 5.4 we shall study explicit inference rules for subeffecting: this is
a related technique for ensuring that the analysis is a conservative extension
of the underlying type system.
5. 2 Theoretical Properties
Having specified the analysis we shall now ensure that it is semantically
correct. Furthermore, the fact that the analysis is a conservative extension
of the underlying type system motivates the following result: whenever we
have a typing in the underlying type system then the set of typings of the
Control Flow Analysis constitutes a Moore family. So as in Section 3.2 (and
Exercise 2. 7) every acceptable expression can be analysed and it has a best
analysis.
As in Sections 2.2 and 3.2, the material of this section may be skimmed
through on a first reading; however, we re-iterate that it is frequently when
[con]
[fn] f- (fn1r x => eo) ---+ (fn1r x => eo)
[!un] f- (fun7r f x => eo) ---+ fn1r x => (eo[f ~ fun1r f x => eo])
f- e1 ---+ (fn7r x => eo) f- e2 ---+ v2 f- eo[x ~ v2] ---+ vo

[app]
f- e1 e2 ---+ vo
f- eo ---+ true f- e1 ---+ v1

f- if eo then e1 else e2 ---+ v1
f- eo ---+ false f- e2 ---+ v2

f- i f eo then e1 else e2 ---+ v2
f- e1 ---+ v1f- e2[x ~ v1] ---+ v2

[let]
f- let x = e1 in e2 ---+ v2
f- e1 ---+ v1f- e2 ---+ v2

[op] if V1 Op V2 =V
f- e1 op e2 ---+ v
Table 5.4: Natural Semantics for FuN.
conducting the correctness proof that the final and subtle errors in the anal-
ysis are found and corrected!
5.2.1 Natural Semantics

To prove the semantic correctness of the analysis we need to define the se-
mantics. Many kinds of semantics would be appropriate but among the
operational semantics we shall now prefer a Natural Semantics (i.e. big-step
operational semantics) without environments because this makes semantic
correctness somewhat easier to establish. This is related to the discussion in
the Concluding Remarks of Chapter 3 about the difference between using a
big-step operational semantics without environments and a small-step oper-
ational semantics with environments; thus our correctness statement will be
somewhat weak in case of looping programs.
Transitions. The Natural Semantics will have transitions of the form

f- e---+ v
meaning that the expression e evaluates to the value v. We shall assume that
eE Exp is a closed expression, i.e. FV(e) = 0, meaning that e does not have
any free variables. The values
v E Val values
will be a subset of the expressions given by the syntax
v ::= c 1 fn1r x => eo provided that FV(fn1r x => eo) =0

where we demand that values are closed expressions. Compared to the Struc-
tural Operational Semantics of Section 3.2, it is not necessary to introduce
environments since the bound variables will be syntactically replaced by their
value as soon as they become free. Hence there is neither need for a close-
construct nor for a bind-construct.
As usual we shall write e1[x t-t e2] for substituting e2 for all free occurrences of
x in e 1 . It will be the case that e2 is closed whenever we use this notation and
therefore there is no risk of variable capture and hence no need to rename
bound variables. Throughout we shall assume that fun?r f x => eo uses
distinct variables for f and x. The semantics is given by Table 5.4 and is
explained below.
The axioms [con] and [fn] express that the constant and the function abstrac-
tion, respectively, evaluate to themselves. For recursive function abstractions
we shall unfold the recursion one level as expressed by the axiom [!un]; note
that the function abstraction being created inherits the program point of the
recursive function abstraction. The rule [app] for application expresses that
first we evaluate the operator, then the operand, and next we substitute the
actual parameter for the formal parameter in the body of the abstraction and
evaluate the body. We have only one rule for application because the axiom
[!un] ensures that ali function abstractions will be of the form fn1r x => eo.
The rules for the conditiona!, the let-construct and the binary operators
should be straightforward.
Example 5. 7 Consider the expression (fnx x => x) (fny y => y) of Ex-

ample 5.1. Using the axiom [fn] we have
f- fnx x => x ----+ fnx x => x

f- fny y => y ----+ fny y => y
f- x[x t-t fny y => y] ----+ fny y => y
and we can apply the rule [app] to get:
f- (fnx x => x) (fny y => y) ----+ fny y => y
In Example 3. 7 we showed how the Structural Operational Semantics deals

with this expression. •
Example 5.8 Next consider the expression loop

let g = (funF f x => f (fny y => y))
in g (fnz z => z)
and let us see how this looping program is modelled in the Natur al Semantics.
First we observe that the axiom [!un] gives
f- funF f x => f (fny y => y) --+

fnF x => ((funF f x => f (fny y => y)) (fny y => y))
so we have replaced the recursive call of f with the recursive function defini-
tion itself. Turning to the body of the let-construct we have to replace the
occurrence of g with the abstraction:
fnF x => ((funF f x => f (fny y => y)) (fny y => y))
The operator will now evaluate to this value and the operand fnz z => z
will evaluate to itself. So the next step is to determine a value v such that
we have an inference tree for
f- (funF f x => f (fny y => y)) (fny y => y)--+ v (5.1)
and after that we are in a position to use the rule for application. The eval-
uation of the operator in (5.1) proceeds as before and so does the evaluation
of the operand and once more we are left with the obligation to construct an
inference tree for the judgement (5.1). Thus we have encountered a circular-
ity and we see that the looping of the program is modelled in the semantics
by the absence of an inference tree. In Example 3.8 we showed how the
Structural Operational Semantics deals with the expression loop. •
It is immediate to verify that if e is a closed expression and f- e --+ v then

all f- e' --+ v' occurring in the corresponding inference tree (in particular
f- e --+ v itself) will have both e' and v' to be closed.
5.2.2 Semantic Correctness

To be able to express the semantic correctness of the analysis we need to
assume that the types of the binary operators op and their semantics are
suitably related. Recall that for the underlying type system we assume that
op takes two arguments with the base types T~P and T~P and gives a result
of type Tap and since base types do not have any annotations we shall now
assume that:
If [] f-cFA VI : T~P and [] f-cFA V2 : T~p then [] f-cFA V : Tap

where v =VI op v2.
This ensures that when given arguments of appropriate types the operator
will return a value of the expected type.
The semantic correctness of the analysis now expresses that the annotated
type foreseen by the analysis will also be the annotated type of the value
obtained by evaluating the expression; this is expressed by the following
subject reduction result:
Theorem 5.9
If [ ] f-cFA e : 7, and f- e -----> v then [ ] f-cFA v : 7.
It follows that if [ ] f- e : 71 ~ 72 and f- e -----> fn1r x => ea then 7f E cpa;

hence the analysis correctly tracks the closures that can result from a given
expression. Also note that if [ ] f- e : 71 -L 72 then e cannot terminate.
In preparation for the proof of the theorem we need a few technical results
of the sort that are standard for type systems. The first result expresses
that the type environment may be extended with information that does not
influence the analysis result:
Fact 5.10 If Î\ f-cFA e : 7 and Î\(x) f2(x) for ali x E FV(e) then
î\ f-cFA e : 7. •
Proof The proof is by induction on the inference tree for Î\ f-cFA e : 7 using that
it is the rightmost occurrence of a variable in a type environment that determines
its type. •
The next result shows that we can safely substitute an expression of the
correct annotated type for a variable:
Lemma 5.11 Assume [ l f-cFA ea : 7o and r[x f--+ 7a] f-cFA e : 7. Then
f f-cFA e[x f--+ eo) : 7. •
Proof The proof is by structural induction on e. Most cases are straightforward
so we shall only present the cases of variables and function abstractions.
The case y. We assume that
r[x f-+ 7o] f-cFA y : 7
so from the axiom [var] of Table 5.2 we have (r[x f-+ 7o])(y) = 7. If X = y then
y[x f-+ eo] = eo and 7 = 7o, and from [ ] f-cFA eo : 7o and Fact 5.10 we get the
required r
f-cFA eo : 7. If X =f- y then y[x f-+ eo] = y and it is easy to see that
r f-cFA Y: 7.
The case fn" y => e. We assume that
r[x f-+ 7b] f-cFA fn" y => e : 7

so, according to rule Lfn] of Table 5.2, it must be the case that 7 = Ty ~ T'
and:
r[x f-+ Ta][y f-+ Ty] f-cFA e : T'
lf X = y then it follows from Fact 5.10 that r[y f-+ Ty] f-cFA e : 7' and since
(fn7r y => e)[x r-+ ea] = fn7r y => e the result follows. So assume that x :/= y;
then (fn7r y => e)[x r-+ ea] = fn7r y => (e[x r-+ ea]). It follows from Fact 5.10 that
r[y f-+ Ty][x f-+ Ta] f-cFA e : 7' and then we get r[y f-+ Ty] f-cFA e[x f-+ ea] : 7' from
the induction hypothesis. Now the result follows using the rule [fn]. •
We now turn to the proof of Theorem 5.9:

Proof The proof proceeds by induction on the inference tree for f- e --> v.
The cases [con] and [fn] are immediate.
The case Lfun]. We assume that
f- fun7r f x => ea --> fn" x => ea[/ r-+ fun" f x => ea]
where f and x are distinct variables. Also we have

[] f-cFA fun" f x => ea : Tx Ta
and according to Table 5.2 this is because [/ r-+ Tx {1r}U<po) 7a][x r-+ Tx] f-cFA ea: 70.
Since [/ r-+ Tx {1r}U<po 1 7a][x r-+ Tx] equals [x r-+ Tx][f r-+ Tx ~ 7a] (because
we assumed that f and x are distinct) it follows from Lemma 5.11 that
[x r-+ Tx] f-cFA ea[/ r-+ fun" f x => ea] :Ta

and hence [] f-cFA fn" x => ea[/ r-+ fun" f x => ea] : Tx {1r}U<po 1 Ta which is the
desired result.
The case [app]. We assume that
because f- e1 --> fn" x => ea, f- e2 --> v2 and f- ea[x r-+ v2] -->va. Also we have
[ ] f-cFA e1 e2 : 7a
and according to Table 5.2 this is because [] f-cFA e1 : T2 ..!4 Ta and [] f-cFA e2 : T2.
The induction hypothesis applied to the inference tree for e 1 gives:
~ 'P ~
[] f-cFA fn" x => ea : T2 ---+ Ta
According to Table 5.2 this can only be the case if 1r E r.p and [x r-+ T2] f-cFA ea : 70.
The induction hypothesis applied to the inference tree for e2 gives
[ ] f-cFA v2 : T2
and by Lemma 5.11 we now get [] f-cFA ea[x r-+ v2] :Ta. The induction hypothesis
applied to the inference tree for ea[x r-+ v2] now gives
[ ] f-cFA va : Ta
and this is the desired result.

The case [i/1]. We assume that
because f- e0 -----+ true and f- e1 -----+ v1. Also we have
[ ] f-cFA if eo then e1 else e2 : r

and from Table 5.2 we see that this is because [ ] f-cFA eo : bool, [ ] f-cFA e1 : r and
[ ] f-cFA e2 : 7. The induction hypothesis gives
[ ] f-cFA v1 : r
The case [ih] is analogous.
The case [let]. We assume that
because f- e 1 -----+ v1 and f- e2 [x r--t vi] -----+ v2. Also we have

[ ] f-cFA let x = e1 in e2 : T2
and this is because [ ] f-cFA e1 : r1 and (x r--t Ti] f-cFA e2 T2. The induction
hypothesis now gives:
( l f- CFA Vl : Tl
From Lemma 5.11 we then get [] f-cFA e2[x r--t v1] : T2 and the induction hypothesis
gives
as required.
The case [op]. We assume that
because f- e1 -----+ v1, f- e2 -----+ v2 and v1 op v2 = v. Also we assume
(] f-cFA e1 op e2 : Tap
and this can only be because (] f-cFA e1 : T,!P and (] f-cFA e2 : T;P. The induction
hypothesis gives [ ] f-cFA v1 : T,!p and [ ] f-cFA v2 : T;P and the desired result that
[ ] f-cFA v : Tap then follows from the stated assumptions about the relationship
between the semantics and the types of the binary operators. •

In Chapter 3 we showed that the set of solutions to the Control Flow Analysis
constituted a Moore family: the greatest lower bound of a set of solutions is
also a solution. (Also see Exercise 2. 7.) From that result it then follows that
all programs can be analysed and that there is a best analysis.
Complete lattice of annotations. A similar development is pos-

sible here except that special care has to be taken concerning the nature of
annotations. We would like to be able to regard the set Ann of annotations
as a complete lattice, and this necessitates a partial ordering
'-Pl ~ <p2 or '-Pl ~ '-P2

that intuitively means that the set '-Pl of program points is included in the
set r.p 2 of program points. One way to formalise this is to say
3r.p' : '-Pl u r.p' = '-P2

where we rely on the axiomatisation of "equal as sets" presented in Table 5.3.
Another way is by means of an explicit system of rules and axioms for in-
ferring judgements of the form '-Pl ~ r.p2; we shall dispense with these details
(but see Exercise 5.3).
One way to ensure that (Ann, ~) is a complete lattice is to demand that
all annotations are subsets of a given finite set; for this one might replace
Pnt by the finite set Pnt* of program points occurring in the expression of
interest. Another possibility will be to change the syntax of annotations to
allow expressing an arbitrary subset of Pnt. Either approach works, since
all that suffi.ces for the subsequent development is to assume that:
(Ann, ~) is a complete lattice isomorphic to (P(Pnt), ~).
The partial ordering on Ann will sometimes be written as ~ and sometimes

as~-
Complete lattice of annotated types. We can now extend the

partial ordering on annotations to operate on annotated types that have the
same underlying type. For this let T E Type be a type and write
TYPe[T]
for the set of annotated types 7 with underlying type T, i.e. such that l7J = T.
Next define Ti ~ f2 for T1, f2 E TYPe[T] to mean that whenever ~ has the
annotation '-Pi in a given position then '-Pl ~ <p2. Formally this is achieved
by:
f1~Tf r.p~r.p' f2~~
- (,[) ....... _, c.o' _,
T1 ....<....t T2 ~ T1 ........__. T2
As an example, (int ~ int) ~ int ~ ( int ~ int) ~ int will
be the case if and only if '-Pl ~ r.p3 and <p2 ~ '-P4· (Note that this ordering
is not contravariant unlike what will be the case for the subtyping to be
introduced in Section 5.4.) Clearly the least element in TYPe[T] will have 0
on all function arrows occurring in T and the greatest element will have Pnt
on all function arrows.
It is straightforward to prove that each (TYPe[r], !;;;;) is a complete lattice.

In a similar way the partial ordering can be extended to operate also on type
environments having the same underlying structure. Finally, suppose that
r f-uL e : T and write
JUDGcFA[r f-uL e: r]
for the set of typings f f-cFA e : 7 such that L·J maps r f-cFA e : 7 to
r f-uL e: T (and hence LfJ = r and LrJ = r). This facilitates extending the
partial ordering !;;;; to operate on the set JUDGcFA[r f-uL e : r] of typings.
Moore family result. We are now ready to state the result about
Moore families:
Proposition 5.12
JUDGcFA[r f-uL e: r] is a Moore family whenever r f-uL e: T.
Proof We assume that r f-uL e : T and prove that JUDGcFA[r f-uL e : r] is a

Moore family. For this we proceed by induction on the shape of the inference tree
for r f-uL e: r. We shall only give the proof for the cases [var], ffn] and [app]; the
other cases follow the same overall pattern. In ali cases let
Y = {(fi f-cFA e : ~) 1 i E I}
bea subset of JUDGcFA[r f-uL e: r]. Using that (TYPe[r'], ~) is a complete lattice
n
for all choices of r' E Type we get that Y exists and that it is defined in a
pointwise manner. (Note that if I = 0 then nY is obtained from r f-uL e : T by
n
placing 0 = Pnt as annotation on ali function arrows.) It remains to show that
nY E JUDGCFA[r f-uL e: r].
The case [var]. The result follows from (nifi)(x) = ni(fi(x)).
The case ffn]. We have r f-uL fn". X=> ea : Tx --+ To because r[x 1-+ Tx] f-uL ea :Ta.
For iEI we have fi f-cFA fn". x =>ea : ~ {"-}u<pi • Tii because of
~- ~ ~
and clearly r'[x ~--+ rx] f-cFA ea : r 0 is an element of JUDGcFA[r[x ~--+ Tx] f-uL ea :ro].
By the induction hypothesis we get (nifi)[x 1-+ ni~] f-cFA ea : niTii and hence
where <p = ni 'Pi.

The case [app]. We now have r f-uL el e2 : To because r f-uL el : 72 --+ To and
r f-uL e2 : 72. For ali i E I we have -·
r' f-cFA el e2 : -:::::i
To because
and clearly fi f-cFA e1 : ~ ~ 7;l is an element of JUDGcFA[r f-uL e1 : T2 ---+ro] and

fi f-cFA e2 : ~ is an element of JUDGcFA[r f-uL e2 : r2]. By the induction hypothesis
we get nifi r el :ni~ ~ ni7il and nifi r e2: ni~ where cp =ni cpi and hence
nifi r el e2 : ni7il
which is the desired result. •

Example 5.13 Consider the expression e:
f (fnx x => x+1) + f (fnv y => y+2) + (fnz z => z+3) (4)
In the underlying type system we have:
[! f-t (int ---t int) ---t int] re: int
In the Control Flow Analysis we have
[f f-t (int ~ int) ~ int] re: int
whenever {X, Y} ~ 'PI· The least solution therefore has <p1 = {X, Y} and
<p2 = 0. This clearly tells us that f is only applied to (fnx x => x+1)
and (fny y => y+2) and not to (fnz z => z+3). A larger solution like
<p1 = {X, Y, Z} and <p2 = {V} would not convey this information. Hence it
seems sensible to ask for the least solution with respect to ~ and the existence
of this solution is guaranteed by Proposition 5.12. •
5.3 Inference Algorithms

The main difference between an analysis expressed in the form of an inference
system (as in Table 5.2) and in the form of an algorithm is that the user of
the inference system is expected to have sufficient foresight to be able to
guess the right types and annotations whereas the implementation of the
algorithm will make use of a mechanism for making tentative guesses that
are later refined. Let us first consider the simple case corresponding to the
underlying type system of Table 5.1.
5.3.1 An Algorithm for the Underlying Type System

Augmented types. The algorithm corresponding to the type system
of Table 5.1 will work on augmented types that allow the use of type variables
to reflect that the details of a type are not fully determined yet:
r E AType augmented types
a E TVar type variables
5.3 Inference Algorithms 301
We shall take:
T int 1 bool 1 TI ---+ T2 1 o:
'a 1 'b 1 'c 1· · ·
Substitutions. A substitution is a finite and partial mapping from type

variables to augmented types, we write
e : TVar ---+fin AType

and note that the domain dom( e) = {o: e is defined on o:} is finite. We
1
shall allow to view a substitution as a total function from type variables to

augmented types, setting e o:= o: whenever o: <ţ dom(e). We shall say that
a substitution e is defined on o: if and only if o: E dom( e).
e
The substitution is called a ground substitution if and only if it maps all type
variables in its domain to ordinary types, i.e. if 't/o: E dom(e) : e o: E Type.
e
The substitution is said to cover r, respectively T, if and only if it is defined
on all the type variables in r, respectively T. Substitutions can be applied to
augmented types in a pointwise manner:
e int int
e bool bool
e(T1 ___, T2) (e TI) ___, (e T2)
eo: T ifeo:=T
We shall write el o e2 for the composition of el and e2' i.e. (el o e2 )T = el (e2 T)
for all augmented types T.
The idea. The type reconstruction algorithm, called WuL, is given two
arguments: an augmented type environment r (mapping program variables
to augmented types) and an expression e. If it succeeds in finding a typing
for the expression then it will return its augmented type T and a substitution
e telling how the type environment has to be refined in order to obtain a
typing. As an example we will have
WuL([x f--7 'a], 1 + (x 2)) = (int, ['a f--7 int---+ int])
because during the inspection of the expression 1 + (x 2) it becomes clear

that x must be a function from integers to integers if the expression is to be
correctly typed. So the idea is that if
WuL(r, e) = (T, e) then ea(e r) f-u e: ea T
for every ground substitution ea that COVers e r and T, i.e. whenever we

replace all the type variables with ordinary types in a consistent way. When
this property holds we shall say that the algorithm is syntactically sound.
In order for the algorithm to be syntactically complete it is also required
that all typings obtainable in the inference system can be reconstructed from
the results of the algorithm. We shall discuss these properties at length in
Subsection 5.3.3.
The algorithm. The algorithm WuL is specified in Table 5.5 and is

explained below. The algorithm asks for fresh type variables at several places.
By this is meant type variables that do not occur in the argument to WuL
and that have not been generated as fresh variables elsewhere; this could be
formalised by supplying WuL with yet another parameter for tracking the
type variables that remain fresh but it is customary not to do so. There is a
small amount of nondeterminism in WuL in that there may be many choices
for the fresh variables; this could be made precise by assuming they are all
numbered and by always supplying the candidate with the smallest number
but again it is customary not to do so.
In the clause for constants we simply note that the type of c is Te and there
is no need to adjust our assumptions r so we return the identity substitution
id: we demand that id o: = o: for all o: and could take id to be the empty
mapping. The clause for variables is similar except that now we consult the
type environment f to determine the augmented type of X.
For function abstraction we assume that the formal parameter has type ax
for O:x being a fresh type variable - so far we have no constraints on the type
of the formal parameter. Then we call WuL recursively on the function body
to determine its type under the assumption that x has type O:x. The resulting
type To and substitution Oo are then used to construct the overall type; in
particular, Oo is used to replace the type variable O:x with a more refined
type since the analysis of the function body may have provided additional
information about the type of the formal parameter.
The clause for recursive function definition is somewhat more complicated.
It starts out in a way similar to the previous clause and requires fresh type
variables O:x and o:o so that we can supply augmented types O:x ---t o:o and O:x
for the occurrences of f and x, respectively, in the analysis of the function
body. However, this will result in two possible types for the function body:
one is the type va~iable o:o (modified by the substitution Oo obtained by
analysing the function body) and the other is the type To obtained from the
analysis of the function body. These two types have to be equal according to
the rule [fn] of Table 5.1 and to ensure this we shall use a unification procedure
UuLi its definition will be discussed in detail below but the idea is that given
two augmented types T1 and T2, UuL (T1, T2) will return a substitution () that
makes them equal i.e. such that () T 1 = () T 2 . In the clause for recursive
function definition we get that 01 (To) = 01 (Oo o:o) so the overall type will
be 01(O o O:x) ---t 01 To. Also we record that the assumptions of r have to be
modified by Oo as well as 01.
WuL(r, c) =(re, id)
WuL(r, x) = (r(x), id)
WuL(r, fn1r x => eo) = let ax be fresh

(ro, Oo) = WuL(r[x f-t ax], eo)
in ((Oo ax)---+ ro, Oo)
WuL(r, fun7r f x => eo) =
let ax, ao be fresh
(ro,Oo) = WuL(r[J f-t ax---+ ao][x f-t ax],eo)
81 = UuL(ro, Oo ao)
in (Ol(Oo ax)---+ 81 To, 81 o Oo)
WuL(r, e1 e2) = let (r1, 01) = WuL(r, el)
(r2, 82) = WuL(Ol r, e2)
a be fresh
03 = UuL(02 T1, r2 ---+a)
in (83 a, 03 o 82 o 81)
WuL(r, if eo then e1 else e2) = let (ro, Oo) = WuL(r, eo)

(r1.01) = WuL(Oo r,e1)
h,02) = WuL(Ol(Oo r),e2)
03 = UuL(02(01 ro), bool)
04 = UuL(03 r2, 83(82 rl))
in (04(03 r2), 04 o 03 o 82 o 01)
WuL(r,let x = e1 in e2) = let (r1,0l) = WuL(r,el)

(r2, 82) = WuL((Ol r)[x f-t r1], e2)
in (r2, 02 o 01)
WuL(r,el op e2) = let (r1,01) = WuL(r,el)

(r2, 82) = WuL(Ol r, e2)
03 = UuL(02 r1, r~P)
84 =UuL(03 T2,T;p)
in (r0 p, 04 o 03 o 82 o 01)
Table 5.5: Algorithm WuL for the underlying type system.
Also the clause for function application relies on the unification procedure.
In this clause we call WuL recursively on the operator and the operand and
we use unification to ensure that the type of the operator T1 (modified by
02) is a function type with an argument type that equals the type r2 of the
operand: 82 TI has to have the form T2 ---+ a. Again we have to record that
the assumptions of r have to be modified by all three substitutions that have
been constructed.
By now the clause for conditiona} is straightforward and similarly the clauses
for the let-construct and the binary operator. (Note that the let-construct
is not polymorphic and therefore no special action is needed to determine the
type of the bound variable; we shall return to the problem of polymorphism
later.)
Example 5.14 Consider the expression (fnx x => x) (fnv y => y) of

Example 5.1. The call
WuL([], (fnx x => x) (fny y => y))
gives rise to the call

WuL([], fnx x => x)
which will create the fresh type variable 'a and return the pair ('a -t 'a, id).
We now have the call
WuL([], fnv y => y)
that creates the fresh type variable 'b and returns ('b -t 'b, id). Thus we get
the following call of UuL
UuL ('a - t 'a, ('b -t 'b) -t 'c)
where 'c is a fresh type variable. As we shall see in Example 5.15 below this
gives rise to the substitution ['a t---t 'b - t 'b] ['c t---t 'b - t 'b] and the initial call
of WuL will return 'b - t 'b and ['a t---t 'b - t 'b]['c t---t 'b - t 'b]. •
Analogy. The placement of substitutions in Table 5.5 may seem ad hoc

at first sight. As an aid to the intuition we shall therefore offer the following
analogy. Consider a society where a number of laws have been passed. One
such law might stipulate that when the owner of a personal computer sells
it, the owner is obliged to comply with the law and in particular provide the
buyer with the original disks for all software that remains on the computer.
Let us focus our attention on a particular owner preparing to sell a computer
and who is determining an acceptable selling price. Then parliament passes
a law stating that whenever original software disks are passed on from one
private person to another, the previous owner has to pay a fee of ten percent of
the original buying price to a government agency combating software piracy.
From this day on the owner of the computer needs to reconsider all the
considerations roade in order to determine the acceptable selling price. In
short: whenever a new law is passed all existing considerations need to be
reconsidered in order to remain valid. - Coming back to Table 5.5, the
typings determined by WuL correspond to the considerations of the owner,
and the substitutions produced by UuL to the new laws being passed by
parliament: whenever a new substitution ( "law") is constructed ali existing
UuL(int, int) id
UuL (bool, bool) id
if a does not occur in T

or if a equals T
otherwise
if a does not occur in T

UuL(a, T) or if a equals T
otherwise
UuL(TI, T2) = fail in all other cases
Table 5.6: Unification of underlying types.
typings ( "considerations") must be suitably modified so as to remain valid;

this is exactly what is achieved by the carefully chosen use of substitutions
in Table 5.5. D
U nification. The algorithm UuL for unifying two augmented types is

shown in Table 5.6. It takes two augmented types TI and T2 as arguments
and if it succeeds it returns a substitution (} such that (} TI = (} T2 •
In the clause for unifying the two function types TI --+ T2 and Tf --+ T~ the
desired result is obtained in two stages: OI ensures that (}I TI = (}I T{ and
hence (02 o OI) TI = (02 o OI) Tf and 02 ensures that 02 (OI T2) = 02 (OI T~); it
follows that 02 o (}I succeeds in unifying the two function types. Note that
the algorithm only fails at top-level if:
• two types with different top-level constructors (by which we mean int,
bool, or --+) are to be unified, or
• a type variable is to be unified with a function type containing that
type variable.
Example 5.15 In Example 5.14 we had the following call of the unifica-
tion procedure:
UuL ('a --+ 'a, ('b --+ 'b) --+ 'c)
It will first give rise to the call UuL ('a, 'b --+ 'b) which returns the substitution
['a ~-----> 'b --+ 'b]. Then we will have the call UuL ('b --+ 'b, 'c) and the substitution
['c ,___. 'b ----+ 'b] is returned. Thus the overall result will be the substitution
['a,___. 'b----+ 'b]['c ,___. 'b----+ 'b] as already used in Example 5.14. •
5.3.2 An Algorithm for Control Flow Analysis

In applying the above ideas to the inference system for Control Flow Analysis
presented in Table 5.2 we are going to face a difficulty. In the underlying type
system two types are equal if and only if their syntactic representations are
the same; we say that types constitute a free algebra. For annotated types,
two annotated types may be equal even when their syntactic representations
are different: int {1rt}U{1r 2 } int equals int {1r2 }u{1rt} ) int because
annotations and types are considered equal modulo UCAl as discussed in
Subsection 5.1.2- we say that annotated types constitute a non-free algebra.
The difficulty we encounter when transferring the development of the previous
subsection to the Control Flow Analysis is that the algorithm WuL relies
on the procedure UuL for unifying two types, and that this algorithm only
applies to types in a free algebra. One way out of this difficulty would be to
use instead an algorithm for unifying modulo UCAl; such algorithms exist
but their properties are not so nice as those of UuL· Another way out of the
difficulty, and the approach we shall take, is to arrange it such that a variant
of UuL can stiH be used by introducing additional mechanisms for dealing
with the annotations: one is the notion of simple types and annotations and
the other is the use of constraints.
Simple types and annotations. The first step will be to restrict

the form of the annotated types so that only annotation variables are allowed
on the function arrows; later we shall combine this with a set of constraints
restricting the values of the annotation variables.
A simple type is an augmented annotated type where the only annotations
allowed on function arrows are annotation variables and where type variables
are allowed in types, and a simple annotation is an annotation where also
annotation variables are allowed:
T E SType simple types
o: E TVar type variables
(3 E AVar annotation variables
cp E SAnn simple annotations
Formally, the syntactic categories are given by:
T .. - int 1bool 11\ _!___. T2 1o:

0: .. 'a l'b l'c 1· · ·
(3 .. - '11'21'31 ...
UcFA(int, int) = id
UcFA(bool, bool) id
!3 72,71
UcFA(T1 """"'--t ~ ~ L 72
~') let Bo = [,B' f-+ .8]
01 = UcFA (O o 71. Oo T;_)
02 = UcFA(01 (Oo 72), 01 (Oo ~))
in (}2 o (}1 o Oo
{
[a f-+ 7] if a does not occur in 7
UcFA(7,a) or if a equals 7
fail otherwise
UcFA(a, 7) = { [a f-+ 7]
fail
if a does not occur in 7
or if a equals 7
otherwise
UcFA (71, 72) = fail in all other cases
Table 5. 7: Unification of simple types.
A simple type environment r then is a mapping from variables to simple

types.
U nification of simple types. Simple types constitute a free algebra

and so we can apply the same technique as in Subsection 5.3.1 to define a
function UcFA of the following form:
UcFA (71 , 72) = (}
Here 71 and 72 are simple types and (} will be a simple substitution: A simple
substitution is a substitution that maps type variables to simple types, and
that maps annotation variables to annotation variables only. Thus a simple
substitution applied to a simple type still gives a simple type. As for UuL
the intention is that (} unifies 71 and 72, i.e. (} 71 = (} 72. In case this is not
possible the outcome of UcFA (71, 72) will be a failure. The unification function
UcFA is defined in Table 5.7 and is explained below.
As before id is the identity substitution and (}' o (}" is the composition of two
substitutions. In the clause for unifying the two function types 71 L 72
and 7f L 72 the desired result is obtained by first ensuring that the
two annotation variables are equal and then proceeding as in the unification
algorithm for the underlying types. Note that UcFA (71, ~) will fail if and only
if UuL ( lTd, l72J) fails.
Example 5.16 Consider the following call of the unification procedure:

1 '1 1 1 '2 1 '3 1
UcFA(a---+ a, ( b---+ b) ---+ c)
We construct the substitution ['3 f--+ '1] and then we perform the call
'2 1 )
UcFA (/a, 1b---+ b
which returns the substitution ['a f--+ 'b ~ 'b]. Then we make the call
1 '2 1 1
UcFA( b ---+ b, c)
and the substitution ['c f--+ 'b ~ 'b] is returned. Thus the overall result will
be ['3 f--+ '1]['a f--+ 'b ~ 'b]['c f--+ 'b ~ 'b]. •
The following fact, whose proof we leave to Exercise 5.8, expresses that the
algorithm is correct. The first part of the result says that the algorithm is
syntactically sound: if it succeeds then it produces the desired result. The
second part says that the algorithm is syntactically complete: if there is some
way of unifying the two simple types then the algorithm will succeed in doing
so.
Fact 5.17 Let 71 and 72 be two simple types.

• If UcFA (71, 72) = () then () is a simple substitution such that () 71 = () 72.
• If there exists a substitution ()" such that ()"71 = ()"72 then there exists
substitutions () and ()' such that UcFA (71, 72) = () and ()" = ()' o (). •
Constraints. Annotated types can contain arbitrary annotations and

simple types can only contain annotation variables. To make up for this
deficiency we shall introduce constraints on the annotation variables. A con-
straint is an inclusion of the form
where f3 is an annotation variable and <p is a simple annotation. A constraint

set C is a finite set of such constraints.
We shall write () C for the set of inclusions obtained by applying the substi-
tution () to all the individual constraints of C: if f3 ;2 <p is in C then () f3 ;2 () <p
is in() C. If C is a constraint set and () is a simple substitution then also () C
is a constraint set.
A type substitution is a substitution that is defined on type variables only
and that maps them to types in TYPe
(i.e. to annotated types without type
5.3 lnference Algorithms 309
and annotation variables); we shall say that it covers r,

respectively 7, if it
is defined on all type variables in r,
respectively 7. Similarly, an annotation
substitution is a substitution that is defined on annotation variables only
and that maps them to annotations in Ann (i.e. to annotations without
annotation variables); it covers r,
respectively 7 or C, if it is defined on all
annotation variables in f, respectively 7 or C. An annotation substitution
(}A solves a constraint set C, written
if and only if it covers C and for each (3 ;;2 <p in C it is the case that (}A (3 is
a superset of, or is equal to, (}A <p.
A ground substitution is an annotation substitution on annotation variables
and a type substitution on type variables. A substitution (} is a ground
validation of (r, 7, C) if and only if it is a ground substitution that covers
r,7 and c c c
and such that (} F (or more precisely, (}A F where (}A is the
restriction of (} to the annotation variables).
The algorithm. We are now ready to define an analogue of the type

reconstruction algorithm WuL· It has the form
WcFA(r, e) = (T, (}, C)

where we demand that r is a simple type environment (i.e. that it maps
variables to simple types), and it will be the case that 7 is a simple type, (} is
a simple substitution, and C is a constraint set of a very special form: it only
contains constraints of the form (3 ;;2 { 1r}. Since WcFA will make use of UcFA
there is also the possibility that WcFA fails. The algorithm WcFA is defined
by the clauses of Table 5.8 and is explained below.
In the clauses for constants and variables we proceed as before and do not
impose any constraints. In the case of function abstraction we shall addi-
tionally use a fresh annotation variable (30 ; it will be the top-level annotation
of the overall type and we shall add a constraint (30 ;;2 { 1r} requiring that
it includes the label 1r of the function definition - this corresponds to the
annotation {1r} U <p used in the rule lfn] of Table 5.2.
The clause for recursive function definition is modified in a similar way. Here
the annotation variable (3 will be used to annotate the function type of f and
the call of WcFA on the body of the function may cause it to be modified to
(} 0 (30 . Next the call of the unification procedure may cause it tobe further
modified to (} 1 ((}o (30 ). Since both (}o and (}1 are simple substitutions we
know that (} 1 ((}o f3o) is an annotation variable so the resulting type will still
be simple. The recursive call of WcFA gives rise to a constraint set C0 that
has to be modified using the substitution (} 1 and as in the clause for ordinary
function abstraction we have to add a new constraint expressing that the
WcFA(f, c) =(re, id, 0)
WcFA(f,x) = (r(x), id, 0)
WcFA(f, fn1r x => eo) = let ax be fresh

(7'o, Oo, Co) = WcFA(f[x 1--t ax], eo)
f3o be fresh
in ( (Oo ax) ~ To, Oo, Co U {/3o ::2 {7r}})
WcFA(f, fun1r f x => eo) =

let ax, a o, f3o be fresh
(7'o, Oo, Co) = WcFA(f[J 1--t ax ~ ao][x 1--t ax], eo)
81 = UcFA(7'o, Oo ao)
in (81 (Oo ax) 01 (llo .Ba)) 81 7'o, 81 o Oo,
(81 Ca) U {Ol(Oo f3o) ::2 {rr}})
WcFA(f,el e2) = let (T1,01,Cl) = WcFA(f,el)

(T2,02,C2) = WcFA(Ol f,e2)
a, f3 be fresh
83 = UcFA(02 1'1. 1'2 ~ a)
in (83 a, 83 o 82 o 81. 83 (82 Cl) u 83 C2)
WcFA(f, if eo then e1 else e2) =
let (To, Oo, Co) = WcFA(f, eo)
(7'1,01,Cl) = WcFA(Oo f,e1)
(1'2, 82, C2) = WcFA(Ol (Oo f), e2)
83 = UcFA(02 (81 7'o), bool)
84 = UcFA (83 1'2, 83 (82 rl))
in (04 (83 1'2), 84 o 83 o 82 o 81 o Oo,
84 (83 (82 (81 Co))) u 84 (83 (82 Cl)) u 84 (83 C2))
WcFA(f, let x = e1 in e2) =
let {Tt, Ot, Cl) = WcFA(f, e1)
(1'2,02,C2) = WcFA((Ol f)[x 1--t 1'1],e2)
in (1'2, 82 o 81, (82 C1) U C2)
WcFA(f,el op e2) = let (7'1,01,Cl) = WcFA(f,el)
(1'2, 82, C2) = WcFA(Ol f, e2)
83 = UcFA (82 1'1, r;P)
84 = UcFA(03 1'2, r;p)
in (Top, 84 o 03 o 02 o 01,
04 (83 (82 Cl)) U 84 (83 C2))
Table 5.8: Algorithm WcFA for Control Flow Analysis.

annotation variable fh (Oo f3o) has to contain the labei rr of the function
definition.
The clauses for the remaining constructs are fairly straightforward modifica-
tions of the similar clauses for WuL· Note that the substitutions are applied
to the constraint sets as well as the types and type environments.
Example 5.18 Returning to the expression (fnx x => x) (fnv y => y) of

Example 5.1 we shall now consider the call:
WcFA([ ], (fnx x => x) (fny y => y))
It gives rise to the call WcFA ( [ ], fnx x => x) which creates a fresh type variable
'a and a fresh annotation variable '1 and returns ('a ~ 'a, id, {'1 2 {X}}).
Then we have the call WcFA([], fny y => y) that creates a fresh type variable
'b and a fresh annotation variable '2 and returns ('b ~ 'b, id, {'2 2 {Y}} ).
Thus we get the following call of UcFA
1 '1 1 1 '2 1 '3 1
UcFA (a ----+ a, ( b ----+ b) ----+ c)
where 'c is a fresh type variable and '3 is a fresh annotation variable. This
gives rise to ['3 1-t '1]['a 1-t 'b ~ 'b]['c 1-t 'b ~ 'b] as shown in Example 5.16
and the initial call of WcFA will return the type 'b ~ 'b, the substitution
['3 1-t '1]['a 1-t 1 b ~ 'b]['c 1-t 'b ~ 'b] and the set {'1 2 {X}, '2 2 {Y}} of
constraints. This corresponds to the typing obtained in Example 5.4. •
Example 5.19 Consider the program loop

let g = (funF f x => f (fny y => y))
in g (fnz z => z)
of Example 5.2 and the call WcFA([ ], loop). This will first give rise to a call
WcFA([], funF f x => f (fny y => y))
that returns the type ('a ~ 'a) ~ 'b and the set {'1 2 {F}, '2 2 {Y}} of
constraints. Then we have a call of WcFA on the body of the let-construct:
WcFA([g 1-t ('a~ 'a)~ 'b],g (fnz z => z))
The call of WcFA on fnz z => z will give the type 'c ~ 'c and the constraint
set {'3 2 {Z} }. The unification procedure will then be called with the types
('a ~ 'a) ~ 'b and ('c ~ 'c) ~ 'd and the resulting substitution
is ['1 1-t '4, '2 1-t '3, 'a 1-t 'c, 'b 1-t 'd]. Thus the application will have type 'd
and the constraint set will be {'3 2 {Z} }. The initial call of WcFA on loop
returns the type 'd and the constraint set {'4 2 {F}, '3 2 {Y}, '3 2 {Z}}.
This corresponds to the typing obtained in Example 5.5. •
As illustrated in the above examples, when the overall call of WcFA cr'
e) gives
(T, (), C) we are only in~erested in the effect of() on the type and annotation
variables occurring in r.
5.3.3 Syntactic Soundness and Completeness

We are now ready to prove the correctness of the algorithm; this will take
the form of a syntactic soundness result and a syntactic completeness result.
Syntactic soundness is a rather straightforward result to prove. This nor-
mally also holds for Type and Effect Systems that are more complex than
the Control Flow Analysis considered here, although the actual details of
the Type and Effect Systems may of course require special treatment going
beyond the techniques covered here.
By contrast, syntactic completeness is a somewhat harder result to prove. For
a complex Type and Effect System it frequently involves establishing a result
about proof normalisation: that the rules of the inference system that are
not syntax directed need only be used at certain places (see Exercise 5.13).
However, in the case of Control Flow Analysis the proof is going to be un-
characteristically simple because both the algorithm WcFA and the inference
system for Control Flow Analysis are defined in syntax directed ways. Thus
the present development does not indicate the breadth of techniques needed
for Type and Effect Systems in general and the the Concluding Remarks will
contain references to the more general situation.
Syntactic soundness. The soundness result expresses that any infor-

mation obtained from the algorithm is indeed correct with respect the the
inference system:
Theorem 5.20
If WcFA (f, e) = (T, (), C) and () 0 is a ground validation of () f, 7
c
and then Oa(O r) f-cFA e : Oc 7.
This theorem may be reformulated as follows: if WcFA (f, e) = (7, (), C) and
Or is a type substitution that covers () f and 7, and if ()A is an annota-
tion substition that covers () f, 7 and C and that satisfies ()A f= C, then
()A ( Or (() r)) f-cFA e : ()A ( Or 7). To see this first note that ()A o Or = Or o ()A
is a ground substitution; next note that given a ground substitution Oc we
may obtain an annotation substitution ()A by restricting Oc to annotation
variables and similarly we may obtain a type substitution Or by restricting
Oa to type variables and clearly Oa =()A o Or = Or o ()A·
Proof The proof proceeds by structural induction on e (because WcFA is defined
by structural induction on e).
The case c. We have WcFA(Î\ c) =(Te, id, 0). Next let (}c bea ground validation of
Î\ clearly it also covers Te
(because Te is a base type) and it also satisfies (}G f= 0.
From the axiom [con] of Table 5.2 it is immediate that
(}c(f) f--cFA c : Te
and since (}c Te = Te this is the desired result.
The case x. We have WcFA(r, x) = (r(x), id, 0). Next let (}c bea ground validation
of r; clearly it also covers r(x) and it satisfies (}G F 0. From the axiom [var] of
Table 5.2 it is immediate that
(}G r f--CFA X : (}c(r(x))

The case fnrr x => eo. We shall use the notation established in the clause for
WcFA(r, fnrr X=> eo). So let (}G bea ground validation of (}o r, (}o ax ~ To, and
C0 U {,80 ; ;:> {'rr}}. Then (}c is a ground validation of (}o(r[x f-+ ax]), ro, and Co.
Hence by the induction hypothesis we get:
(}c((}o f}[x f-+ (}c((}o ax)] f--cFA eo : (}c To
Since (}c f= Co U {,Bo ; ;:> {71'}} we have (}G ,Bo ; ;:> {71'} so we can apply the rule [fn] of
Table 5.2 and get
~ Oa !3o ~
(}G((}o f) f--cFA fnrr X=> eo: (}G((}o ax) -------> (}G To
which is the desired result.

The case funrr f x => eo. We shall use the notation already established in the
clause for WcFA(r, funrr f X=> eo). So let (}G bea ground validation of (}l((}o r),
(}l((}o ax) Ol(Oo !3o) (}1 To, and ((}1 Co) U {(}l((}o ,Bo) ; ;:> {7r}}. Then (}G o (}1 is a
ground validation of (}o r,
(}o ax ~ ro and Co. Since (}1 ro = (}1 ((}o a 0 ) by Fact
5.17 we also have that (}G o (}1 is a ground validation of (}O (}O ax ~ (}o ao r,
and Co. Hence we can apply the induction hypothesis and get:
Since (}1 ro= (}l((}o ao) and (}c f= ((}1 Co)U{(}l((}o ,Bo) ; ;:> {7r}} we get (}c((}l((}o ,Ba));;;:>
{71'} so we can apply the rule [tun] of Table 5.2 and get
(}G((}l((}o r)) f--cFA funrr f X=> eo: (}G((}l((}o ax)) Oa(Ol(Oo f3o)) (}G((}l To)

The case e1 e2. We shall use the notation already established in the clause for
WcFA(r, el e2). So let (}G be a ground validation of (}3((}2((}1 r)) and (}3 a and
(}3 ((}2 C!) U (}3 C2. Let (}~ bea ground extension of (}c upon (}3((}2 r1) and (}3 T2.
Then (}~o (}3 o (}2 is a ground validation of (}1 r, r1 and C1. Hence we can apply
the induction hypothesis to e 1 and get:
(}~ ((}3 ((}2 ( (}1 r))) f--cFA el : (}~ ((}3 ( (}2 Tl))
Similarly O~ o 03 is a ground validat ion of 82 (81 f), r2 and C2. Hence we can apply
the induction hypothesis to e2 and get:
o~ (03 (02 (01 r))) f-cFA e2 : o~ (03 T2)

Since 83(82 r1) = (83 r2) ..!!.a.L (83 a) follows from Fact 5.17 we can use the rule
[app] of Table 5.2 and get
8~(83(82(81 f))) f-cFA e1 e2 : 8~(83 a)

which is equivalent to Oc(03(02(01 r))) f-cFA el e2 : Oc(03 a) and this is the desired
result.
The cases i f eo then e1 else e2, let x = e1 in e2 and e1 op e2 are analogous. •
Syntactic completeness. It is not enough to show that WcFA is syn-

tactically sound: an algorithm that always fails will indeed be a syntactically
sound implementation of our analysis. We shall therefore be interested in a
result saying that any judgement of the Annotated Type System can in fact
be obtained by the algorithm:
Theorem 5.21
Assume that f is a simple type environment and e' f f-cFA e : 7'
e'
holds for some ground substitution that covers f. Then there
c
exists 7, e, and ee such that
• WcFA(r, e) = (7, e, C),
• ee is a ground validation of e f' :Ţ and c'

• ee o e = e' except on fresh type and annotation variables (as
created by WcFA(r,e)), and
• ee :r = 7'.
Proof The proof is by induction on the shape of the inference tree; since the
Annotated Type System of Table 5.2 is syntax directed this means that the proof
follows the syntactic structure of e. Without loss of generality we may assume that
O' is not defined on type and annotation variables that are freshly generated in the
call WcFA(f, e).
The case c. We have O' f f-cFA c: 7' and 7' =Te. Clearly WcFA(f,c) = (rc,id,0) so
it suffices to set Oc = O' and clearly Oc 7' = 7'.
The case x. We have O' f f-cFA x: 7' because 7' = O'(r(x)). Clearly WcFA(f,x) =
(r( x), id, 0) so it suffices to set Oc = 0'.
The case fn" x => eo. We have
where c.p' is an annotation (i.e. it does not contain any annotation variables) and
from Table 5.2 we get that also:
((}' r)[x >--t :;;,] f-cFA eo : T/;
Let now ax bea fresh type variable and note that ax fţ. dom( O'). Define O" by
if (=ax
otherwise
where ( can either be a type variable or an annotation variable. Then we also have:
By the induction hypothesis there exists ro, Oo, Co and (}~ such that:
WcFA(r[x f--t ax], ea)= (ro,Oo,Co),

(}~ is a ground validation of (Oo f)[x >--t Oo(ax)], ro, and Co,
(}~ o 00 = (}" except on fresh type and annotation variables
created by WcFA(r[x >--t ax], eo)
Next let {30 be a fresh annotation variable and define:
f) 1' ={ {'Il'} u c.p' if ( = f3o

a '> (}~ ( otherwise
Then we get:
Ba is a ground validation of Oo f, (Oo ax) ~ To and Co U {!3 ~{'Il'}},

Ba o 00 = (}' except on fresh type and annotation variables
created by WcFA(r, fn.". x => eo),
f) a ((} O f3n. ~) _ ~, {."-}U<p 1 ~,
ax __._.._, To - Tx > To
This is the desired result.

The case fun.". f x => eo. We have
where c.p' does not contain annotation variables and according to Table 5.2 this is
because:
(O' f)[J >--t:;;, {."-}u'l'' rWx
>--t :;;,] f-cFA eo: T~
Let ax, a 0 and {30 be fresh type and annotation variables and note that they are
not in dom(O'). Define O" by:
if (=ax
~,
Tx
O" ( ~ {
{'Il'} u c.p'
To
~,
if ( = f3o
if ( = ao
(}' ( otherwise
Then we also have:
By the induction hypothesis there exists Ta, Ba, Ca and B~ such that:
WcFA(Î'[j ~---+ax J!sl... aa][x ~---+ax], ea)= (T'o,Ba,Ca)

B~ is a ground validation of Ba(Î'[j ~---+ ax J!sJ.... aa][x ~---+ ax]), Ta, and Ca
B~ o Ba = B" except on fresh type and annotation variables
created by WcFA (· · · , ea)
Since B~ (Ba aa) = B" aa = 7;; = B~ Ta it follows from Fact 5.17 that there exists B1
and Ba such that UcFA(Ba aa, 7a) = B1 and B~ =Ba o B1. Hence
Ba is a ground validation of B1(Ba Î'),B1(Ba ax) fi!Ciio i3o)~ B1 Ta,

and (B1 Ca) U {B1(Ba,Ba) 2 {'rr}}
Ba o B1 o Ba = B' except on fresh type and annotation variables
created by WcFA (· · · , fun" f x => ea)
Ba(B1(Ba ax) 111 (fio i3o) B1(Ba aa)) = T~ {1r}U<p' ~ T~

The case e1 e2. We have
()' Î' ~CFA e1 e2 : %
and according to Table 5.2 this is because:
By the induction hypothesis applied to e1 there exists T'1, B1, C1 and Bi; such that:
WcFA(r,el) = (7l,Bl,cl)
Bi; is a ground validation of B1 f, 71, and C1
Bi; o B1 = B' except on fresh type and annotation variables
created by WcFA(B' r, el)
Ba 71 = 72 ..........., 7a
1 ........ _,(J)' . ..........,
Then we have
Ba1 ( Bl ~
r) f-cFA e2 : ~
72
so by the induction hypothesis applied to e2 there exists T'2, B2, C2 and B~ such
that:
WcFA(Bl f, e2) = (72, B2, C2)
B~ is a ground validation of B2 (B1 r), T'2 and C2
B~ o B2 = Bi; except on fresh type and annotation variables
created by WcFA (· · · , e2)
It then follows that:
8~ is a ground validation of 82(81 r), 82 7'1, 82 C1, 72, and C2

8~ o 82 o 81 = 8' except on fresh type and annotation variables
created by WcFA ( · · · , e t) and WcFA ( · · · , e2)
Tt ) = "'
8G2 (8 2 ~ "'' ;;:ta
T2 -'-> ,,
8~ 72 = 7~
Next let a and f3 be fresh and define:
if (=a
if ( = f3
otherwise
Since 8~(82 71) = 8~(82 71) = ~ ..:L.. 76 = 8~ 7:J ..:L.. 7b = 8~(72 ../!..." a) it follows
from Fact 5.17 that there exists 83 and 8a such that UcFA (82 71, 72 ../!..." a) = 83 and
8~ = 8a o 83. It follows that
8a is a ground validation of 83(82(81 r)), 83 a, and 83(82 C1) u 83 C2

8a o 83 o 82 o 81 = 8' except on fresh type and annotation variables
created by WcFA(· · ·, e1 e2)
8a(83 a) = 8~ a= 76

The cases if ea then e1 else e2, let x = e1 in e2 and e1 op e2 are analogous. •

Since WcFA generates a set of constraints the statement of syntactic soundness
(Theorem 5.20) is a little weaker than usual: if the constraints cannot be
solved then we cannot use the soundness result to guarantee that the result
produced by WcFA can be inferred in the inference system.
This suggests showing that the constraints always have solutions; in line with
previous developments in this book we shall prove a stronger result. For this
let AV(C) be the set of annotation variables in C.
Lemma 5.22 If WcFA(f, e) = (T, O, C) and X is a finite set of annotation

variables such that X 2 AV( C), then
{()A 1 ()A f= C A dom(() A) = X A ()A is an annotation substitution}
is a Moore family. •
Proof Let C be a finite set of constraints of the form f3 2 r.p where r.p E SAnn
and such that X 2 AV( C) where X is a finite set of annotation variables; it will
not be of importance that C is generated by WcFA· Let Y be a possibly empty
subset of the set displayed in the lemma. Each element of Y will be an annotation
substitution with domain X and that satisfies C. By setting
for {3 E X
we define an annotation substitution (} with dom( 8) = X. For each {3 2 'P in C and

(}Ain Y we have
(}A f3 2 (}A 'P 2 (} 'P
(sin ce 'P is monotone in any free annotation variables) and hence:
This establishes the result. •

Consider now the call WcFA (f, e) (T, (), C) and the problem of finding a
ground substitution Oa that covers () f, 7 and C. After the statement of
Theorem 5.20 we made it clear that Oa can always be written as ()A o ()T for
an annotation substitution ()A covering () f, 7 and C and a type substitution
()T covering () f and 7. The choice of the type substitution ()T must be
performed by the user of WcFA; one possibility is to let ()T a = int for all
type variables a in () f and 7. The existence of an annotation substitution
()A now follows from Lemma 5.22.
Corollary 5.23 If WcFA(f, e) = (7, O, C) then there exists a ground val-

idation Oa of() f, 7 and C. •
r
Proof Let (}T be given by (}T a = int for ali type variables a in (} and 7; clearly
(}T r
covers (} and 7. Next let X be the set of annotation variables in(} r, r
and C;
then Lemma 5.22 guarantees the existence of an annotation substitution (}A that
covers (}r, c
T and and such that (}A F c.
Taking 8c = (}A o (}T we obtain a
ground validation of 8 7 and r, c. •
The result obtained by choosing a type substitution is only unique in case
there are no type variables present in () f and 7. If there is at least one
type variable present then the result of using ()T displayed above will differ
from the result of using ()~ given by ()~ a = bool for all type variables a
in() f and 7. In general a type substitution ()~ may have ()~ a E TYPe[ra]
for an arbitrary underlying type 7 0 • However, in case TYPe[ra] has more
than one element one is likely to prefer the least element since it has empty
annotations on all function arrows (but see Exercise 5.9).
In a similar way one is likely to prefer the least annotation substitution
guaranteed by Lemma 5.22. Keeping in mind that all constraints in C have
the form f3 2 {1r} for f3 E AVar and 1r E Pnt, we simply set:
() {3 = { {1r 1 {3 2 {1r} is in C} if {3 E AV(C)

A undefined otherwise
5.4 Effects 319
It is immediate that dom(OA) = AV(C) and that (}A f= C. If also dom(O) =

AV( C) and (} f= C then it is immediate that Vf3 : (} f3 2 (}A f3 which we may
write as (} ;;;;) (}A. This shows that (}A as constructed above is indeed the least
element of the Moore family displayed in Lemma 5.22.
5.4 Effects
The Type and Effect System for Control Flow Analysis is fairly simple: it is
a syntax directed system using a form of subeffecting and the annotations are
just sets. Much more powerful Type and Effect Systems can be constructed
by allowing subtyping, let-polymorphism or polymorphic recursion; the re-
sulting analyses will be more powerful and, not surprisingly, the techniques
required for the implementation will be more demanding.
Subtyping and the various notions of polymorphism can be combined but for
the sake of simplicity we shall present them one at a time. We shall first
present a Side Effect Analysis for an extension of the FuN language with
assignments; it will use subeffecting and subtyping. Then we shall present
an Exception Analysis for an extension of FuN with exceptions; it will use
subeffecting, subtyping as well as polymorphism. Finally, we shall present
a Region Analysis for the FUN language; it will be based on polymorphic
recursion.
5.4.1 Side Effect Analysis

Syntax. Let us consider an extension of the language FUN (Section 5.1)
with imperative constructs for creating reference variables and for accessing
and updating their values:
e::=···lnew7rx :=e1 ine2l !xlx :=eole1; e2
The idea is that new7r x : = e1 in e2 creates a new reference variable called x

and initialises it to the value of e1; the scope of the reference variable is e2 but
we shall want the creation of the reference variable to be visible also outside
its scope so as to be able to determine whether or not functions may need
to allocate additional memory. The value of the reference variable x can be
obtained by writing ! x and it may be set to a new value by the assignment
x : = eo. The sequencing construct e1 ; e2 first evaluates e1 (for its side
effects) and then e2.
Example 5.24 The following program computes the Fibonacci number

of a positive number x and leaves the result in the reference variable r:
newR r:=O
in let fib = funF f z => if z<3 then r:=!r+1
else f(z-1); f(z-2)
in fib x; !r
The program creates a new reference variable r and initialises it to O, then it

defines the function fi b, applies it to the value of x and returns the value of r.
The statement r: =! r+1 in the body of the recursive function will increment
the value of r each time it is executed and each call of fi b x will increase
the value of r with the Fibonacci number of x. •
The aim of the Side Effect Analysis is to record:
For each subexpression which locations have been created, ac-

cessed and assigned.
So for the function fib in Example 5.24 the analysis will record that it
accesses and assigns the reference variable created at program point R.
Semantics. Before presenting the analysis let us briefly sketch the se-
mantics of the language. To distinguish between the various incarnations
of the new-construct we shall introduce locations (or references) and, as for
the imperative languages of Chapter 2, the configurations will then contain
a stare component mapping locations to their values:
c; E Store = Loc --tfin Val
The values of Val include the constants c, the (closed) function abstractions
e
of the form fn7r X => e and the locations E Loc. The semantic clauses of
Table 5.4 are now modified to trace the store in a left-to-right evaluation as
for example in the following clause for the let-construct:
f- (e1, c;1) - - t (VI , c;2) f- (e2 [X t--t VI] , c;2) - - t ( V2 , c;3)
f- (let x = e1 in e2, c;I) - - t (v2, c;3)
For the new constructs we then have the following axioms and rules (explained
below):
f- (el, c;l) (vi. c;2) f- (e2[x 1--t eJ, c;2[e 1--t vl]) - - t (v2, c;3)
--t
f- (new7r x := e1 in e2,c;1) - - t (v2,c;3)

where e does not occur in the domain of c;2
5.4 Effects 321
In the rule for new we evaluate e1, create a new location ~ which is initialised
to the value of e 1 , and then we syntactically replace all occurrences of x
with that location so that all subsequent references to x will be to ~- We
exploit this when defining the semantics for the constructs for accessing and
updating the reference. Note that the value returned by the assignment will
be the value being assigned.
Annotated types. In the Side Effect Analysis a location will be rep-

resented by the program point where it could be created. We shall therefore
define the annotations (or effects) cp E AnnsE by:
cp ::= {!1r} 1{1r:=} 1{new1r} 1C{Jl Ucp210

The annotation !1r means that the value of a location created at 1r is accessed,
1r: = means that a location created at 1r is assigned, and ne"lm that a new
location has been created at 1r. As for the Control Flow Analysis we shall
consider annotations equal modulo UCAL We shall need a set ro of program
points defined by
ro ::= 1r 1 ro1 U ro2 1 0
also to be interpreted modulo UCAl; we shall write ro = { 1r1, · · ·, 7rn} for a

typical element.
The annotated types 7 E Type5E are now given by:
~
7 ::= J.nt
o 1bool 1~71 'P ~1
----t 72 refro ~
7
Here ref ro 7 is the type of a location created at one of the program points in
ro and that will contain values of the annotated type 7. As before the type
environment f will map variables to annotated types.
Example 5.25 Consider the Fibonacci program
newR r:=O
in let fib = funF f z => i f z<3 then r:=!r+1
else f(z-1); f(z-2)
in fib x; !r
of Example 5.24. The variable r has the annotated type ref{R} int and the
variable fib has type int {!R,R:=}> int since it maps integers to integers
and whenever executed it may, as a side effect, access and update a reference
created at the program point R. •
Typing judgements. The typing judgements for the Side Effect Anal-
ysis will be of the form:
f f-sE e : 7 & cp
[con] f f--sE C : Te & 0

[var] r f--sE X: T& 0 ifÎ'{x)=T
[Jn]
Î'[/ f-t Tx ~ To][x f-t Tx] f--sE eo : To & cpo

[!un]
r f--sE flmn- f X => eo : Tx ~ To & 0
[app]
r f--sE el : T2 ~ To & 'Pl r f--sE e2 : T2 & 'P2
f f--sE e1 e2 : Ta & 'Pl U 'P2 U cpo
[ifl
r f--sE eo : bool & cpo r f--sE el : T & 'Pl r f--sE e2 : T & 'P2
r f--sE if eo then el else e2 : T & 'Po u 'Pl u 'P2
[let]
r f--sE el : TI & 'Pl r[x f-t 7)] f--sE e2 : T2 & 'P2
r f--sE let X = el in e2 : T2 & 'Pl u 'P2
[op]
r f--sE e1 : T 1p
~
0 & 'Pl r f--sE e2 : T 2p & 'P2
~
0
f f--sE e1 op e2 : Top & 'Pl U 'P2
[dereJl f f--sE ! X : T & { ! 71"1' ... ' ! 71"n}
f f--sE e : T & <p ~

[ass] ~ if r(x) = ref{7r)· .. ,7rn} T
r f--sE X := e: T & 'P u {rrl:=, ... '7rn:=}
f f--sE e1 :TI & 'Pl f[x f-t ref{1r} T1] f--sE e2 : T2 & 'P2
[new]
f f--sE new7r x : = e1 in e2 : T2 & {'Pl U 'P2 U {newrr})
[seq]
f f--sE e1 : T1 & 'Pl f f--sE e2 : T2 & 'P2
f f--sE e1 ; e2 : T2 & 'Pl U 'P2
f f--sE e: T & cp
[sub] if T ::::; T1 and <p ~ cp'
f f--sE e : T' & <p'
Table 5.9: Side Effect Analysis.

5.4 Effects 323
The idea is that under the assumption f, the expression e will evaluate into a
value with the annotated type 7 and that during computation the side effects
expressed by r.p might take place. The analysis is specified by the axioms and
rules of Table 5.9.
In the clauses [con] and [var] we record that there are no side effects so we use
0 for the overall effect. The premise of the clause [fn] gives the effect of the
body of the function and we use that to annotate the arrow of the function
type whereas we use 0 as the overall effect of the function definition itself:
no side effects can be observed by simply defining the function. A similar
explanation holds for the recursive function definition, the only difference
being that the assumption about f in the premise has to use the same effect
as the one determined from the function body. In the rule [app] we see how
the information comes together: the overall effect is what we can observe
from evaluating the argument e1, what we can observe from evaluating the
argument e2 , and what we get from evaluating the body of the function called.
The rules [i~, [let] and [op] are straightforward.
Turning to the axioms and rules involving reference variables we make sure
that we only assign values of the appropriate type to the variable. Also,
in each of the cases we make sure to record that a location at the relevant
program point has been created, referenced or assigned. The rule [seq] is
straightforward and the final rule [sub] will be explained below.
Example 5.26 The following program
newAx:=1
in (news y:=!x in (x:=!y+1; !y+3))
+ (newc x:=!x in (x:=!x+1; !x+1))
evaluates to 8 because both summands evaluate to 4. The first summand has

type and effect
int & {newB, !A, A:=,! B}
and the second summand has type and effect
int & {new(, ! A, C: =, ! C}
because the reference variable that is updated is the local one. Hence
int & {newA, A:=, ! A, newB, ! B, new(, C: =, ! C}
is the type and effect of the overall program. It follows from the effect that
the variable being created at B (y in the program) is never reassigned after
its creation. This might suggest transforming the news-construct into a let-
construct (i.e. let y=! x in (x: =y+1; y+3)). •
Subeffecting and subtyping. The purpose ofthe rule [sub] in Table

5.9 is to ensure that we obtain a conservative extension of the underlying type
system. The rule is really a combination of a separate rule for subeffecting
f f-sE e : T & r.p if 'P s;;; r.p'

f f-sE e : f & r.p'
and a separate rule for subtyping:
f f-sE e : f & r.p iff:Sf'

f f-sE e : f' & r.p
Here r.p s;;; r.p' means that r.p is "a subset" of r.p' (modulo UCAl) as discussed in
Subsection 5.2.3 (and Exercise 5.3). The ordering f:::; f' on annotated types
is derived from the ordering on annotations as follows:
f :::; f' f' :::; f w s;;; w'
refw T :S refw' T'
Note that the order of the comparison is reversed for arguments to functions;
we say that f 1 --':P..._. f 2 is contravariant in f 1 but covariant in r.p and f 2 . (To
familiarise oneself with this idea just pretend that the types are really logical
propositions and that ~ as well as :::; mean logical implication; then it
should be clear that the rule is the right one.) Also refw T is covariant in w
and both covariant in T (when the reference variable is used for accessing its
value as in ! x) and contravariant in T (when the reference variable is used
for assignments as in x : = · · ·). This turns out to be essential for semantic
correctness to hold.
This form of subtyping we shall call shape conformant subtyping because
f 1 :::; f 2 implies that the two annotated types have the same underlying types,
i.e. lfd = lT2J and hence that T1 and T2 have the same "shape". (There are
more permissive notions of subtyping than this, and we shall return to this
issue in the Concluding Remarks.)
Example 5.27 Consider the following program
newAx:=1
in (fn f => f (fn y => !x) + f (fn z => (x:=z; z)))
(fn g => g 1)
where we have omitted the labels on the function definitions. The program
evaluates to 2 because each summand evaluates to 1.
The type and effect of the two arguments to f are
. {lA}
1nt ~ int & 0
. {A:=}
1nt ~ int & 0
5.4 Effects 325
and when f has the type

.
( l.nt {!A,A:=} . ) {!A,A:=}
----t J.nt int
the application of f to the arguments will be well-typed: we have

.
( J.nt {!A}
----t int
) < (int {!A,A:=}
int
)
{A:=} {!A,A: =}
(int ----t int) < (int int)
and may use the rule for subtyping to change the types of the arguments to
the type expected by f.
If instead we had only used the rule for subeffecting we would be obliged to
let the two arguments to f have type and effect:
{A:=, !A} & 0
int int
{A:=, !A}
int int & 0
This is indeed possible by using the rule for subeffecting just before the rule
for function abstraction. •
The combined rule [sub] for subeffecting and subtyping gives rise to a conser-
vative extension of the underlying type system. This would also have been
the case if we had adopted either the rule for subeffecting or the rule for
subtyping. However, had we incorporated no additional rule then this would
not be the case.
Remark. One can make a distinction between "Annotated Type Systems"

and "Effect Systems" but it is a subtle one and it is hardly fruitful to distin-
guish them in a formal way; yet intuitively there is a difference. The analysis
presented in this subsection is truly an Effect System because the annotations
relate neither to the input nor the output of functions; rather they relate to
the internal steps of the computation. By contrast the analysis of Subsection
5.1 is an Annotated Type System because the annotations relate to inten-
sional aspects of the semantic values: what function abstraction might be the
result of evaluating the expression. •
5.4.2 Exception Analysis

Syntax. As our next analysis we consider an Exception Analysis; the aim
of this analysis is to determine:
For each expression, what exceptions might result from evaluating

the expression.
These exceptions may be raised by primitive operators (like division by zero)

or they may be explicitly raised in the program. Furthermore, there may be
the possibility of trapping an exception by means of executing an expression
designed to overcome the source of the abnormal situation. To illustrate this
scenario we extend the syntax of expressions in FuN (Section 5.1) as follows:
e ::= · · · 1 raise 8 1 handle 8 as e1 in e2
The exception is raised by the raise-construct. If e2 raises some exception

81 then handle 82 as e1 in e2 will trap the exception in case 81 = 82 and
this means that e1 will be executed; if 8 1 # 82 we will continue propagating
the exception 8 1 . We take a simple-minded approach to exceptions and use
strings to denote their identity.
Example 5.28 Consider the following program computing the combina-

torial ( ~ ) of the values x and y of the variables x and y:
let comb = fun f x => fn y =>

if x<O then raise x-out-of-range
else if y<O or y>x then raise y-out-of-range
else if y=O or y=x then 1
else f (x-1) y + f (x-1) (y-1)
in handle x-out-of-range as O in comb x y
The program raises the exception x-out-of-range if x is negative and in

the body of the let-construct this exception is trapped and the value O is
returned. The program raises the exception y-out-of-range if the value of
y is negative or larger than the value of x and this exception is not trapped
in the program. •
Semantics. Before presenting the analysis let us briefly sketch the se-
mantics of the language. An expression can now give rise to an exception so
we shall extend the set Val of values to include entities of the form raise
8. The semantic clauses of Table 5.4 then have tobe extended to take care
of the new kind of values. For function application we shall for example add
three rules
f- e1 ~ raise 8
f- e1 e2 ~ raise 8
f- e1 ~ (fn1r x => eo) f- e2 ~ raise 8

f- e1 e2 ~ raise s
f- e1 ~ (fn1r x => eo) f- e2 ~ v2 f- eo[x t--t v2] ~ raise 8
f- e1 e2 ~ raise 8
5.4 Effects 327
reflecting that an exception can be raised in any of the subcomputations in

the premise of rule [app]. Similar rules are added for the other constructs.
We can then specify the meaning of the new constructs by the following
axioms and rules:
f- raise 8 ----t raise 8
if v2 -=/:- raise 8
f- e2 ----t raise s f- e1 ----t v1

f- handle 8 as e1 in e2 ----t v1
Note that the expression e2 in handle 8 as e1 in e2 may also raise an ex-
ception other than 8 in which case it will be propagated out of the handle-
construct. Similarly, the expression e1 may raise an exception which will then
be propagated out of the handle-construct.
Annotated types. The purpose of Exception Analysis is to determine

which exceptions might be raised and not trapped in the program. We shall
therefore take the annotations to be sets of exceptions. To get a more flexible
type system and a more powerful analysis we shall use a polymorphic type
system. This means that we shall allow the annotated types to contain
type variables and also we shall allow the annotations to contain annotation
variables. So the annotations (or effects) cp E AnnEs will be given by
cp ::= {8} 1'Pl Ucp2101 f3
and the annotated types 7 E TypeEs will be given by:
7 ::= int 1bool 1r1 .!:.... r2 1a
As usual effects will be considered equal modulo UCAL To express the poly-
morphism concisely we introduce type 8chemes. They have the form
â ::= \7'((1, · · ·, (n).r
where ( 1, · · · , (n is a (possible empty) list of type variables and annotation
variables; if the list is empty we simply write 7 for \7'().7.
Example 5.29 Consider the function fnF f => fnx x => f x. We can give
it the type schema
'1 0 1 1
\i 'a, 'b, 11. ('a ---+ 'b) ---t ('a ---+ 'b)
which has instances like

.
( J.nt {x-out-of-range} 0 {x-out-of-range} . )
- - - - - - - t int) ---t (int -------+ J.nt
and (int ~ bool) ~ (int ~ bool). •

[con] f f-Es C : Te & 0

[va~ f f-Es X: â & 0 if r(x) = â
[In]
Î'[f 1----t 7x ~ 7o][x 1----t 7x] f-Es eo : 7o & cpo

[!un]
r f-Es fun'll" f X => eo : 7x ~ 7o & 0
r f-Es el : 72 ~ Tb & cpl r f-Es e2 : 72 & !p2

[app]
r f-Es el e2 : 7o & !pl u !p2 u cpo
r f-Es eo : bool & cpo r f-Es el : 7 & !pl r f-Es e2 : 7 & !p2
[i~
r f-Es i f eo then el else e2 : 7 & cpo u !pl u !p2
r f-Es el : âl & !pl r[x I--t âl] f-Es e2 : 72 & !p2
[let]
r f-Es let X = el in e2 : 72 & !pl u !p2
1 2
r f-Es e1 :Tap
~
& !pl r f-Es e2 :Tap &
~
!p2
[op]
f f-Es e1 Op e2 :Tap & !p1 U !p2
[raise] r f-Es raise s: 7 & {s}
r f-Es el : 7 & !pl r f-Es e2 : 7 & !p2

[handle]
r f-Es handle sas el in e2: 7 & !pl u (cp2\{s})
r f-Es e : 7 & cp
[sub] if 7 ::; T' and cp s;; cp'
f f-Es e : 7' & cp'
r f-Es e : 7 & cp
[gen]
f f-Ese: \i((l, · · ·, (n).7 & cp
if (1, ... , (n do not occur free in r and cp
f f-Ese: \i((l, · · · ,(n).7 & cp

[ins]
f
f-Es e : (0 7) & cp
if(} has dom(O) s;; {(l,···,(n}
Table 5.10: Exception Analysis.

5.4 Effects 329
Typing judgements. The typing judgements for the Exception Anal-

ysis will be of the form
Î' f-Es e : â & <p
r
where the type environment now maps variables to type schemes. As ex-
pected â denotes the type schema of e, and <p is the set of exceptions that may
be raised during evaluation of e. The analysis is specified by the axioms and
rules of Table 5.10. Most of the axioms and rules are straightforward modifi-
cations of those we have seen before; in the rule [let] the use of a type schema
for the let-bound variable is going to give us the required polymorphism.
The axiom [raise] ensures that a raised exception can have any type and
the effect records that the exception s might be raised. The rule [hand le]
then determines the effects of its two subexpressions and records that any
exception raised by e1 and any exception except s raised by e2 is a possible
exception for the construct. Formally, <p \ { s} is defined as follows: {s} \ {s} =
0, {s'} \ {s} = {s'} if s' -j. s, (<p U<p') \ { s} = (<p \ { s}) U (<p1 \ { s} ), 0\ {s} = 0
and (3 \ {s} = (3. (We shall consider alternative definitions shortly.)
The rule [sub] is the rule for subeffecting and subtyping and the ordering
7 :::; 7' on types is given by
as was also the case in Subsection 5.4.1.

The rules [gen] and [ins] are responsible for the polymorphism. The generali-
sation rule [gen] is used to construct type schemes: we can quantify over any
type or annotation variable that does not occur free in the assumptions or in
the effect of the construct; this rule is usually used before applications of the
rule [let]. The instantiation rule [ins] can then be used to turn type schemes
into annotated types: we just apply a substitution in order to replace the
bound type and annotation variables with other types and annotations (pos-
sibly containing type variables and annotation variables); this rule is usually
used after applications of the axiom [var].
Example 5.30 The program
let f = fn g => fn x => g x

in f (fn y => if y < O then raise neg else y) (3-2)
+ f (fn z => if z > O then raise pos else 0-z) (2-3)
evaluates to 2 because each of the summands evaluates to 1.

We may analyse f so as to obtain the type schema
~ 0 'o
V 'a, 'b, 'o.('a --+ 'b) --+ ('a --+ 'b)
and we may analyse the two functional arguments to f so as to obtain:
int ~ int&0
int ~ int&0
We can now take two instances of the type schema for f: to match the first
argument of f we use the substitution ['a ~ int; 'b ~ int;' O ~ {neg}] and to
match the second argument we use ['a~ int;'b ~ int;'O ~ {pos}]. Hence
the type and effect of each summand is
int & {neg}
int & {pos}
and therefore
int & {neg, pos}
is the overall type and effect of the entire program.
If we did not avail ourselves of polymorphism we would have to rely on
subeffecting and subtyping and let f have the type
.
(J.nt {neg,pos} . ) 0 (. {neg,pos} . )
J.nt --+ J.nt J.nt
which is more imprecise than the type scheme displayed above, although we
would stiH be able to obtain int & {neg, pos} as the overall type and effect
of the entire program. •
Remark. The judgements of the Exception Analyses were of the form

r l-Es e : â & tp but nonetheless most axioms and rules of Table 5.10 have
conclusions of the form r l-Es e: T & tp. By changing rules [i.fl, [let], [raise],
[hand le] and possibly [sub] one can obtain a more liberal system for Exception
Analysis. We leave the details for Exercise 5.15.
In the rule [hand le] we make use of the notation <p \ { s} and we next defined
!3\ {s} = f3 even though f3 might later be instantiated to {s}. Since !3\ { s} ~ f3
should hold for all instantiations of [3, this is semantically sound (correspond-
ing to what happens in the rule [sub]). To definea less approximate system
it would be natural to let
tp::=··· 1 tp\{s}
and then to extend the axiomatisation of UCAl to deal with set difference. •
5.4.3 Region Inference

Let us once again consider the language FUN as introduced in Section 5.1.
The purpose of Region lnference is to facilitate implementing FuN in a stack-
based as opposed to a heap-based regime as is usually the case; since the
5.4 Effects 331
(ri,o1)
(r1,1)
(r2;o,)
(r2,1)
D (r3,o3)
(r3,1)
r1 r2 r3
Figure 5.1: The memory model for the stack-based implementation of FuN.
stack-based regime is quite efficient in reusing dead memory locations without

relying on explicit garbage collection this might lead to an efficient implemen-
tation. But functions are statically scoped and can produce other functions
as results, so it is by no means clear that a stack-based regime should be
possible; the purpose of region inference is to analyse how far locally allo-
cated data can be passed around so that the allocation of memory can be
performed in an appropriate manner. This leads to a memory model for the
stack-based regime where the memory is a stack of dynamic regions (r1, r2,
r3, · · ·) and each dynamic region is an indexed list (or array) of values as
illustrated in Figure 5.1.
Syntax. To make this feasible we shall introduce a notion of extended

expressions that contain explicit information about regions. To this end we
introduce region names, region variables, and static regions
rn E RN ame region names

e E RVar region variables
r E RegR 1 regions
as follows:
rn .. - r11 r21 r31 · · ·
{! .. - "1 1"2 1"3 1...
r .. - e 1rn
The syntax of extended expressions
ee E EExp
is given by:
ee c at r 1 x 1 fn1r x => eeo at r 1 fun1r f [I?J x => eeo at r 1 ee1 ee2

if eeo then ee1 else ee2 llet x = ee1 in ee2 1 ee1 op ee2 at r
ee[r] at r lletregion ein ee
e
Here we write for a possibly empty sequence [!1, · · · , Qk of region variables
and similarly r for a possible empty sequence r1' ... 'Tk of regions. The
main point of the extended expressions is that if a subexpression explicitly
produces a new value then it has an explicit placement component, "at r",
that indicates the region in which the value is (tobe) placed. The letregion-
construct explicitly allows the deallocation of the regions, §, that are no longer
needed and the placement construct, ee[r] at r, allows us to explicitly place a
"copy" of ee (typically a recursive function) in the region r. The construct for
recursive function definitions explicitly takes a sequence of region variables
as parameters; intuitively, this ensures that the various incarnations of the
recursive function can have their local data in different regions.
Example 5.31 The relationship between expressions and extended ex-

pressions will be clarified when presenting the typing judgements below. For
now we merely state that the expression e given by
(let x = 7 in fnv y => y+x) 9
will give rise to the extended expression ee:
letregion [!1, [!3, [!4

in (let x = (7 at t?l)
in (fny y => (y+x) at {!2) at [!3) (9 at [!4)
Here the value 7 is placed in the region [! 1, the value of x+y in region [!2,
the function named Y in the region [! 3 and the argument 9 in region [!4.
The final value (which is 7 + 9 = 16) is therefore to be found in region [! 2.
All other regions ([! 1 , [! 3 , and [! 4 ) no longer serve any purpose and can be
deallocated; this is made explicit by the letregion-construct. In the version
of the program that is actually run we should replace the metavariables [!1,
[! 3 and [! 4 by region variables 11 1, 11 2, and "3 and furthermore the free region
variable [! 2 should be replaced by a region name such as r1. •
Semantics. The Natural Semantics of expressions is given by Table 5.4

and we now devise a Natural Semantics for the extended expressions so as to
make the role of regions clear. The transitions takes the form
p f- (ee,<;)_____, (v,<;')
where p is an environment, ee is an extended expression, <; and <; 1 are stores

(as in Figure 5.1) and v is an expressible value. Formally we shall use the
5.4 Effects 333
domains:
p E Env Var*-+ EVal

V E EVal RN ame x Offset
o E Offset N
<; E Store RName -+fin (Offset -+fin SVal)
w E SVal
Here Var* is the finite set of variables in the extended expression ee* of
interest, a stare is a stack of regions (where the stack is modelled as a finitary
mapping from region names), a region is a list of storable values (where the
list is modelled as a finitary mapping from indices called offsets), and a
storable value is given by
w ::= c (x, ee, p)

1 1 (e, x, ee, p)
consisting of ordinary constants, closures, and so-called region polymorphic
closures. In addition to the formal parameter, the body of the function,
and the environment at the definition point, a region polymorphic closure
also contains a list of formal region parameters that have to be instantiated
whenever the function is called - in this way it is explicityly ensured that
the local data can be properly placed in the store for each function call.
To simplify the notation we shall view a store as an element of RN ame x
Offset -+fin SVal and so write <;(r, o) for <;(r)(o) etc. All ordinary values are
"boxed" which means that they are always placed in the store and hence an
expressible value is always a pair consisting of a region name and an offset.
The semantics is defined in Table 5.11 and is explained below. We intend
that an extended expression does not contain free region variables when eval-
uated and hence many r's have become rn's. The axiom [con] for constants
explicitly allocates a new offset in the relevant region and places the constant
in that cell. The axiom [var] for variables does not involve the allocation of
a new offset and merely performs a lookup in the environment.
The axiom [fn] for function abstraction allocates a new offset where it stores
an ordinary closure consisting of the formal parameter, the body of the func-
tion, and the current environment. The axiom [fun] for recursive functions
constructs a region polymorphic closure that records the list of formal region
variables to be instantiated by means of the placement construct explained
below; also note that recursion is handled by updating the current environ-
ment with a reference to the function itself.
The rules [app], [iA], [if2 ] and [let] should be straightforward and the rule [op]
for binary operations allocates a new offset for the result.
The rule [place] takes care of the situation where an extended expression
(such as a variable or a recursive function definition) evaluates to a region
[con] p f- (cat rn,c;)-----> ((rn,o),c;[(rn,o) f---+ c])

if o rţ dom(c;(rn))
[var] pf- (x,c;)-----> (p(x),c;)
[fn] p f- ((fn1r x => ee 0 ) at rn, c;) ----->

((rn,o),c;[(rn,o) f---+ (x,eeo,p)])
if o rţ dom( c;(rn))
[!un] p f- ((fun1r f[e] x => eeo) at rn,c;)----->

((rn,a),c;[(rn,o) f---+ (§,x,eeo,p[f f---+ (rn,a)])])
if o rţ dom( c;(rn))
p f- (ee1, '>1)-----> ((rn1, al), '>2) p f- (ee2, '>2)-----> (v2, '>3)

po[x f---+ v2] f- (eeo, '>3) -----> (vo, '>4)
[app]
p f- (ee1 ee2, '>1) -----> (vo, '>4)
if <:;3(rn1,al) = (x,eeo,po)
p f- (eeo, '>1) -----> ((rn, o), '>2) p f- (ee1, '>2) -----> (v1, '>3)
[iA]
p f- (if eeo then ee1 el se ee2, '>1) -----> (v1, '>3)
if '>2(rn, o)= true
p f- (eeo, '>1) -----> ((rn, o), '>2) p f- (ee2, '>2) -----> (v2, '>3)
p f- (if eeo then ee1 else ee2, '>1) -----> (v2, '>3)
if c;2(rn, a) =false
p f- (ee1,'>1)-----> (v1,'>2) p[x f---+ v1] f- (ee2,<:;2)-----> (v2,'>3)

[let]
p f- (let x = ee1 in ee2,<:;1)-----> (v2,'>3)
p f- (ee1, '>1) -----> ((rn1, a1), '>2) p f- (ee2, '>2) -----> ((rn2, a2), '>3)
[ap]
p f- ((ee1 op ee2) at rn, '>I) -----> ((rn, o), '>3[(rn, a) f---+ w])
if <:;3(rn1, al) op <:;3(rn2, a2) = w and o rf. dom(c;3(rn))
p f- (ee,c;1)-----> ((rn',o'),'>2)
[place]
p f- (ee[rn] at rn, c;1)
-----> ((rn,a),c;2[(rn,a) f---+ (x,eeo[Qf---+ rn],po)])
if o rţ dom( '>2 (rn)) and <:;2(rn', o') = (§, x, eeo, po)
p f- (ee[§ f---+ rn], '>1 [rn f---+ []]) -----> (v, '>2)
[region]
e
p f- (letregion in ee, '>1) -----> (v, '>2 ~rn)
if {rn} n dom(c;) = 0
Table 5.11: Natural Semantics for extended expressions.

5.4 Effects 335
polymorphic closure. The placement construct ee[f1 at r then allocates a

new cell in the region r and stores a copy of the region polymorphic closure
in the cell except that it ensures that the list of formal region parameters is
replaced by a list of the actual region names; this is an important feature for
allowing each recursive call of a function to allocate its auxiliary data locally
on the stack rather than being lumped together (in the heap) with data from
other recursive calls.
Finally, the rule [region] for the letregion-construct allocates new unused
region names to be used instead of the region variables, evaluates the enclosed
extended expression, and finally deallocates the newly allocated region names;
formally, dom(<;~rn) =dom(<;)\ {rn} and V(rn, o) E dom(<;~rn): <;(rn, o)=
(<;~rn)(rn, o).
Annotated types. When analysing the extended expressions we shall
want to keep track of those regions that may be affected during evaluation:
in what regions do we place (or put) data and from what regions do we
access (or get) data. This is somewhat analogous to the Side Effect Analysis
of Subsection 5.4.1 and will be taken care of using the effects to be defined
below. Another purpose of the analysis is to keep track of the regions in
which the values reside. To this end we shall say that an extended type is a
pair
7@r
consisting of an annotated type and the region where the value resides. For-
mally, annotations (or effects), annotated types and type schemes
'P E AnnR1 effects

7 E TypeR1 annotated types
a E SchemeR1 type schemes
are given by:
'P .. - {put r} 1 {get r} 1 'Pl U 'P2 1 0 1 f3

T int 1 bool 1 (71 @rl) ~ (72@r2) 1 a
V(a1, ···,an), (!31, · · ·, f3m), [e1, · · ·, ek].7
V(a1, ···,an), ([31, · · ·, f3m).7
Here we distinguish between two kinds of type schemes: compound type

schemes (with [e]) to be used for recursive functions and ordinary type
schemes (without [e]). We shall write 7 for V(), ().7 whereas we insist on
writing V[ ].7 for V(),(), [ ].7; in this way the two kinds of type schemes can
always be distinguished. The use of an annotation variable, [3, in the anno-
tation placed on the function arrow, {3.<p, is related to the use of simple types
in Section 5.3 and is mainly of interest for the inference algorithm; for our
present purposes f3.c.p can be read as f3 U c.p although the inference algorithm
will view it as the constraint f3 2 f3 U c.p.
Example 5.32 Returning to the extended expression

letregion {!1, {!3, {!4
in (let x = (7 at e1)
in (fny y => (y+x) at e2) at {!3) (9 at {!4)
of Example 5.31, the subexpression 7 at e1 will have the annotated type

int@e1, the function abstraction (fny y => (y+x) at e 2) at e3 will have the
annotated type
where c.p = {get {!4, get e1, put {!2}, and the overall expression will have the
extended type int@e2· •
Typing judgements. It would be quite feasible to define typing judge-

ments for verifying that extended expressions are correctly typed. However,
the main use of region inference is to facilitate the implementation of FuN
and for this reason we shall touch upon the discussion initiated in Section 1.8
and let the typing judgements also describe how to translate expressions into
extended expressions. This suggests using typing judgements of the form
f f-R1 e "-"*ee : 7@r & c.p
where f is a type environment mapping variables into extended type schemes
that are pairs consisting of a type scheme and a region.
The analysis is defined in Tables 5.12 and 5.13 and is explained below. The
axiom [con] for constants inserts an explicit placement component and records
the placement in the effect. The axiom [var] for variables is straightforward
as it involves no explicit placements.
The rule [In] for ordinary function abstraction transforms the body of the
function and then inserts an explicit placement component for the function
itself. The rule [tun] for recursive functions involves a restricted form of poly-
morphic recursion (excluding type variables as this would be undecidable):
polymorphic recursion means that when analysing the body of the function
we are allowed to use the recursive function polymorphically. This general-
ity gives much more precise type information and is essential for the success
of region inference. For conciseness the rule has been presented in a manner
where the rule for ordinary functions is needed to analyse the premise; clearly
the rule could have been expanded so as to be syntax directed. The rules for
application, conditiona!, local definitions and operators are straightforward.
Then we have a rule [sub] for subeffecting and subtyping; clearly one could de-
cide to dispense with subtyping in which case subeffecting could be integrated
with function abstraction as illustrated in Section 5.1.
5.4 Effects 337
[con] fI-RI c~ cat r: (rc@r) & {put r}
[var] f f-RI X ~ X : {j & 0 ifr(x) = â
[fn]
f I-RI fnn x => eo ~ (fnn x => eeo) at r :
((Tx@rx ~ ro@ro)@r) & {put r}
f[J f--+ (Vi}, [/?1.r)@r)i-RI fnn X=> eo ~

(fnn x => eeo) at r : (T@r) & cp
[!un]
fI-RI funn f x => eo ~ (funn f [/?1 x => eeo) at r :
((Vi], [/?1.7)@r) & cp
if iJ and ff do not occur free in f and cp
fI-RI e1 ~ ee1: ((T2@r2 ~ ro@ro)@ri) & 'Pl

f I-RI e2 ~ ee2 : (r2@r2) & 'P2
[app]
fI-RI eo ~ eeo : (bool@ro) & 'Po

fI-RI e1 ~ ee1 : (T@r) & 'Pl fI-RI e2 ~ ee2 : (r@r) & 'P2
[i./]
fI-RI i f eo then e1 else e2 ~ i f eeo then ee1 else ee2 :
(r@r) & 'Po u 'PI u 'P2 u {get ro}
f I-RI e1 ~ ee1 : (â1 @rl) & 'Pl

Î'[x f--+â1 @rl]I-RI e2 ~ ee2 : (T2@r2) & 'P2
[let]
[op]
fi-RI e1 op e2 ~ (ee1 op ee2) at r:
(Top@r) & 'Pl U 'P2 U {get r1, get r2, put r}
Table 5.12: Region Inference Analysis and Translation (part 1).

There are two rules [gen1 ] and [ge7t2] for generalising over type variables. One
applies to ordinary types and the other to compound type schemes. In both
cases we could have adapted the rule so as also to generalise over (additional)
region and effect variables; however, even when doing so, the type inference
is quite separate from the region and effect inference.
[sub]
f f-RI e ""' ee : (T@r) & '{J
f f-RI e""' ee: (T'@r) & '{J 1

if 7 ::::; T' and 'P s::;: 'P'
f f-RI e ""' ee : (T@r) & '{J
f e""' ee: ((\iâ.7)@r) & 'P

f-RI
if â do not occur free in r and 'P
f f-RI e""' ee: ((ViJ, [e].7)@r) & 'P

f f-RI e""' ee: ((\iâ,iJ, [e].7)@r) & 'P
if â do not occur free in r and 'P
f f-RI e""' ee: ((\iâ, i].7)@r) & 'P

f f-RI e""' ee: (((} 7)@r) & 'P
if (} has dom( O) s::;: { â, iJ}
f f-RI e""' ee: ((\iâ, iJ, [e].7)@r) & 'P

f e""' ee[Oe] at r' : (((} 7)@r') & 'P U {get r, put r'}
f-RI
if (} has dom( O) s::;: { â, iJ, e'}
f e ""' ee : (7@r) & '{J

f-RI
[region]
f f-RI e
e ""' letregion in ee : (T@r) & '{J 1
if 'P' = Observe(Î', 7, r )( 'P) and eoccurs in 'P but not in 'P'
Table 5.13: Region Inference Analysis and Translation (part 2).
There are two inference rules [ins1] and [ins2] for instantiating a type scheme.
One is for ordinary types schemes and is invisible as far as the syntax of the
extended expression is concerned. The other is for compound type schemes
and is visible in the extended expression in that an explicit placement con-
struct is introduced; additionally the effect records that the value has been
accessed and placed again. Both rules would typically be used immediately
after the axiom for variables.
The rule [region] for the letregion-construct uses an auxiliary function,
Observe, to reduce the effect to what is visible from the outside; region vari-
ables that are no longer visible can then be encapsulated within the program.
The auxiliary function may be defined as follows:
Observe(Î', 7, r')( {put r}) { 0{put r} if r occurs in r, 7, or r'

otherwise
Observe(r,7,r')({get r}) {0 {get r} if r occurs in r' 7, or r'

otherwise
5.5 Behaviours 339
Observe(f, 7, r')(rp1 U rp2) Observe(f, 7, r')(rpi) U Observe(f, 7, r')(rp 2)

Observe(f, 7, r')(0) 0
Observe(f, 7, r')(f3)
{~ if (3 occurs in
otherwise
f, 7, or r'
Example 5.33 In Example 5.31 we considered the expression e

(let x = 7 in fny y => y+x) 9
and the extended expression ee:
letregion Ql, Q3, Q4

in (let x = (7 at QI)
in (fny y => (y+x) at Q2) at Q3) (9 at Q4)
One can now show that [] f---R1 e""' ee: (int@Q2) & {put Q2}· •
5.5 Behaviours
So far the effects have had a rather simple structure in that they merely
denote sets of atomic actions like accessing a value or raising an exception.
The effects have not attempted to capture the temporal order of these atomic
actions. Often such information would be useful, for example to check that
a variable is not accessed until after it has been assigned a value. In this
section we shall show how to devise a Type and Effect System where effects
(called behaviours) are ah le to record such temporal ordering in the context
of a Communication Analysis for a fragment of Concurrent ML.
5.5.1 Communication Analysis

Syntax. Let us consider an extension of the language FuN with con-
structs for generating new processes, for communicating between processes
over typed channels, and for creating new channels. The syntactic category
e E Exp of expressions is now given by:
e ::= · · · 1 channel7r 1 spawn ea 1 send e1 on e2 1 recei ve ea 1 e1; e2 1 ch
Here channel7r creates a new channel identifier (denoted ch above), spawn ea

generates a new parallel process that executes ea, and send v on ch sends the
value v to another process ready to recei ve a value by means of recei ve ch;
sequential composition is as before. Channel identifiers
ch E Chan channel identifiers

Figure 5.2: The pipeline produced by pipe [f 1 , f 2 ] inp out.
are created dynamically and are given by:
ch ::= chanl 1 chan2 1 ...
Also we shall assume that the constants, c E Const, not only include integers
and booleans but also a special value called unit and denoted by () ; this is
the value to be returned by the spawn and send constructs.
Example 5.34 In this example we shall imagine that the expressions are
extended with operations on lists: isnil e tests whether or not the list e
is empty, hd e selects the first element and tl e selects the remainder of
the list. We now define a function pipe that takes a list of functions, an
input channel and an output channel as arguments; it constructs a pipeline
of processes that apply the functions to the data arriving at the input channel
and returns the results on the output channel (see Figure 5.2). It makes use
of the function node that takes a function, an input channel and an output
channel as arguments and it is defined as follows:
let node = fnF f => fn1 inp => fno out =>
spawn ((funH h d => let v = receive inp
in send (f v) on out;
h d) ())
in funp pipe fs => fn1 inp => fno out =>
if isnil fs then node (fnx x =>x) inp out
else let ch = channelc
in (node (hd fs) inp ch; pipe (tl fs) ch out)
To deal with the empty list the function produces a process that just applies
the identity function (denoted id in Figure 5.2). •
Semantics. We shall begin by defining the operational semantics of the

sequential fragment of the language and then show how to incorporate it into
the concurrent fragment. This will make use of a notion of evaluation context
in order to obtain a succinct specification of the semantics. The sequential
fragment is evaluated in an eager left to right manner and does not need any
5.5 Behaviours 341
(fn1r x => e) v--+ e[x ~----+ v]
let x =v in e --+ e[x ~----+ v]
fun1r f x => e--+ (fn1r x => e)[f ~----+ (fun11" f x => e)]
if true then e1 else e2 --+ e1
i f false then e1 el se e2 --+ e2
v; e--+ e
Table 5.14: The sequential semantics.
notion of a store, a state or an environment. A fully evaluated expression

gives rise to a value which is a constant, a channel identifier or a function
abstraction. This may be modelled by
v E Val values
defined by:
v ::= c 1 ch 1 fn1r x => eo
There is no need to package the function abstraction with an environment
because the semantics will treat a function application (fn11" x => eo) v by
substituting v for x in eo yielding eo[x ~----+ v].
Part of the sequential semantics is specified in Table 5.14. In the manner of
a Structural Operational Semantics it axiomatises the relation
for when the expression e 1 evaluates to e 2 in one step. However, it does not
describe how e 1 may evaluate to e2 as a result of a subcomponent e 11 of e 1
evaluating to e12 unlike what has been the case for the Structural Operational
Semantics used so far. As an example Table 5.14 cannot be used to show
that (1 + 2) + 4--+ 3 + 4 although it can be used to show that 1 + 2--+ 3.
To recover from this shortcoming we shall make use of evaluation contexts;
these are expressions containing one hole which is written [ ]. Formally,
evaluation contexts E are given by:
E .. - [ ]\ E e 1 v E \let x = E in e
if E then e1 else e2 E op e v op E 1 1
send E on e 1 send v on E 1 receive E \ E;e

Here the syntax ensures that E is an expression containing exactly one hole
while e is an ordinary expression without any holes. The definition of E may
be read as follows: you are allowed to evaluate an expression on its own,
you may evaluate the function part of an application, you may evaluate the
argument part of an application only after the function part has been fully
evaluated etc. We shall write E[e] for the expression obtained by replacing
the hole of E with e; so for example if E is [] + 4 then E[e] is e + 4. We
dispense with the detailed definition of E[e] because it is straightforward:
since the hole in E never occurs in the scope of a bound variable there is no
risk of variable capture.
The basic idea is to stipulate that e1 evaluates to e2 in one step (e1 =} e2) if
there exists E, e10 and e2o such that e1 = E[e10], e10---+ e2o and e2 = E[e2o].
As an example, (1+2)+4 =} 3+4 by taking E tobe [ ]+4, e10 tobe 1+2 and
e20 to be 3. Note that having E op e as an evaluation context corresponds
to having an inference rule
as in Table 3.3. As already said, an advantage of using evaluation contexts is

that the description of the semantics often becomes more succinct; we shall
benefit from this below.
The concurrent semantics operates on a finite pool, PP, of processes and a
finite set, CP, of channels. The set of channels keeps track of those chan-
nels that have been generated so far; this allows us to evaluate cbannel1r
by generating a new channel that has never been used before. The pool of
processes both keeps track of the processes spawned so far and of the expres-
sion residing on each process; this allows us to allocate new processes when
an expression is spawned and to let distinct processes communicate with one
another. Formally
p E Proc processes
is defined by
p ::= proc1 1 proc2 1 · · ·
and we take
CP E Pfin(Chan)
PP E Proc ---+fin Exp
where it will be the case that each P P(p) is a closed expression. We shall
write PP[p: e] for PP' given by dom(PP') = dom(PP) U {p}, PP'(p) = e
and PP'(q) = PP(q) for q =1- p.
The concurrent semantics is specified in Table 5.15. It is a Structural Oper-
ational Semantics that axiomatises the relation CP1, PP1 =} CP2, PP2 for
when one configuration CP1, PP1 in one step evolves into another configu-
ration CP2, PP2. Thanks to the use of evaluation contexts all clauses can
5.5 Behaviours 343
[seq] CP, PP[p: E[e 1]] =?- CP, PP[p: E[e2]]

if e1 -+ e2
[chan] CP, PP[p: E[channel11']] =?- CP U {ch}, PP[p: E[ch]]

if ch (/. CP
[spawn] CP, PP[p: E[spawn eo]] =?- CP, PP[p: E[O]][po: eo]
if Po (/. dom(PP) U {p}
[comm] CP, PP[p1 : E![send v on ch]][p2 : E2[receive ch]]

=?- CP, PP[p1 : E1[0]][p2: E2[v]]
if P1 =f. P2
Table 5.15: The concurrent semantics.
be written succinctly. The clause [seq] incorporates the sequential semantics

into the concurrent semantics (and corresponds to the discussion of e1 =} e2
above). The clause [chan] takes care of the allocation of channels: channel11'
is replaced by a fresh channel identifier ch. The clause [spawn] generates a
new process, initialises it to the expression to be executed, and replaces the
spawn-construct by the unit value. Finally, the clause [comm] allows syn-
chronous communication between distinct processes: the recei ve-construct
is replaced by the value being sent and the send-construct is replaced by the
unit value.
Annotated types. The purpose of the Communication Analysis is to

determine the communication behaviour of each expression: what channels
will be allocated, what type of entities will be sent and received over channels,
and what is the behaviour of the processes being generated. Furthermore,
we are interested in recording the temporal order (or "causality") among
these actions: what takes place before what. There are several ways to
formalise this and we shall choose one where the inference system is not
overly complicated (but where instead the inference algorithm presents some
challenges).
To formalise our idea we introduce the following syntactic categories:
7 E TypecA types
cp E AnncA annotations (or behaviours)
r E RegcA regions
'& E SchemecA type schemes
Types are much as before but extended with a unit type (for the unit value)
and a type for channels:
7 ::= o: 1 bool 1 int 1 unit 1 r1 ~ T2 1 7 chan r
Type variables, a E TVar, are as before.

Behaviours differ from the annotations and effects used so far in that we shall
not merely use union for combining them:
cp .. - !31 A 1 cp1; 'P2 1 'Pl + 'P2 1 rec(3.cp

7 chan r 1 spawn cp 1 r!f 1 r?r
Behaviour variables, (3 E AVar, are as before and the behaviour A is used for
atomic actions that do not involve communication; in a sense it corresponds
to the empty set in previous annotations although it will be more intuitive to
think of it as the empty string in regular expressions or as the silent action
in process calculi. The behaviour 'Pl; 'P2 says that 'Pl takes place before 'P2
whereas 'Pl + 'P2 indicates a choice between 'Pl and 'P2 (as will be the case
for the conditiona!); this is reminiscent of constructs in regular expressions
as well as in process algebras. The construct rec(3.cp indicates a recursive
behaviour that acts as given by cp except that any occurrence of (3 stands
for rec(3.cp itself; it is typically used whenever there is explicit or implicit
recursion in the program.
The behaviour 7 chan r indicates that a new channel has been allocated over
which entities of type 7 can be communicated; the region r indicates the set
of program points (see below) where the creation could have taken place.
The behaviour spawn cp indicates that a new process has been generated and
that it operates as described by cp. Next r!f indicates that a value is sent
over a channel of type 7 chan r and r?r indicates that a value is received
over a channel of that type; this is reminiscent of constructs in most process
algebras (in particular CSP).
Regions have a bit more structure than in Subsection 5.4.3 because now we
shall also be able to take the union of regions:
r ::= { 1r} 1 (} 1 r1 U r2 1 0
Region variables, (} E RVar, are as before. In Subsection 5.4.3 the static

regions were used to ensure that at run-time data would be allocated in the
same dynamic regions; here regions are used to identify the set {1r1, · · · , 1rn}
of program points where a channel might have been created. (So program
points now play the role of region names.) However, these regions will not
appear explicitly in the syntax of expressions, types or behaviours.
Type schemes have the form
â ::= \i((t. · · ·, (n).r

where ( 1 , · · · , (n is a (possibly empty) list of type variables, behaviour vari-
ables and region variables; if the list is empty we simply write 7 for \7'().7.
5.5 Behaviours 345
Example 5.35 Returning to the program of Example 5.34, the node func-
tion is intended to have the type schema
V'a, 'b, '1, 111, 112. ('a ~ 1b) ~ ('a chan 111) ~ ('b chan 112) ~ unit
where cp = spawn(rec 12. ("1?'a; '1; "2!'b; '2))
corresponding to the function argument having type 'a ~ 1b, the input
channel having type 'a chan 111 and the output channel having type 'b chan 112.
When supplied with these arguments the node function will spawn a process
that recursively will read on the input channel, execute the function supplied
as its parameter, and write on the output channel - this is exactly what is
expressed by cp.
The pipe function is intended to have the type schema
V'a, 11, "1, 112.(('a ~ 'a) list ~ ('a chan ("1 U {C} ))
~ ('a chan "2) ..:i..., unit
where cp' = rec '2. (spawn(rec 13. (("1 U {C})?'a; A; "2!'a; '3))
+'a chan C; spawn(rec '4. (("1 U {C})?'a; 11; C!'a; 14)); 12)
where the first summand in the body of cp' corresponds to the then-branch
where node is called with the identity function (which has behaviour A) and
the second to the else-branch of the conditiona!. Here we see that a channel
is created, a process is spawned and then the overall behaviour recurses. We
shall return to these types schemes after presenting the typing rules. •
Typing judgements. The typing judgements for the Communication

Analysis will be of the form
f f-cA e : & & cp
where the type environment f maps variables to type schemes (or types), &
is the type scheme (or type) for the expression e, and cp is the behaviour that
may arise during evaluation of e. The analysis is specified by the axiom and
rules of Tables 5.16 and 5.17 and have many points in common with those
we have seen before; the differences are explained below.
The axioms [con] and [var] for constants and variables differ from the similar
axioms in Table 5.10 in that A is used instead of 0. A similar remark holds
for the two rules [fn] and [fun] for functions; note that [!un] does not explic-
itly demand cp 0 to be of the form rec(J'.cp' although this will frequently be
necessary in order to satisfy the demands (using the ordering on behaviours
to be introduced below). In the rule [app] for function application we now
use sequencing to express that we first evaluate the function part, then the
argument and finally the body of the function. In the rule [i.fl for conditiona!
we additionally use choice to express that only one of the then- and else-
branches are taken. Then the rules [let] and [op] should be straightforward.
[con] r f--cA c : & ATe
[var] r f--cA â & A

X : ifÎ'(x)=â
[fn]
Î'[f ~----> Tx ~ fo](x ~----> Tx] f--cA eo : To & 'Po

[tun]
r f--cA fun'lr f X => eo : Tx ~ To & A
[app]
r f--cA el : T2 ~ To & 'Pl r f--cA e2 : T2 & 'P2
r f--cA el e2: To & 'Pli 'P2i 'Po
(i~
r f--cA eo : bool & 'Po r f--cA el : T & 'Pl r f--cA e2 : T & 'P2
r f--cA i f eo then el else e2: T & cpo; ('Pl + 'P2)
[let]
f f--cA e1 : â1 & 'Pl Î'(x ~----> â1] f--cA e2 : :J='2 & 'P2
r f--cA let X =el in e2 : T2 & 'Pli 'P2
[op]
r f--cA e1 : Tap1
~
& 'Pl r f--cA e2 : Tap2
~
& 'P2
r f--cA el op e2: Tap & 'Pli'P2;A
Table 5.16: Communication Analysis (part 1).

The axiom [chan] for channel creation makes sure to record the program
point in the type as well as the behaviour, the rule [spawn] encapsulates the
behaviour of the spawned process in the behaviour of the construct itself and
the rules [send] and [recei ve] for sending and receiving values over channels
indicate the order in which the arguments are evaluated and then produce the
behaviour for the axiom taken. The rules [seq] and [ch] are straightforward
and the rules [gen] and [ins] are much as in Table 5.10.
Example 5.36 Consider the following example program:

let ch = channelA
in (send 1 on ch; send true on ch)
Intuitively, this program should be rejected because the channel ch is used

for communicating values of two different types thereby violating type safety.
To see that the program is indeed rejected, first observe that the rule [chan]
gives:
[] f--cA channelA: 'a chan {A} & 'a chan {A}
Then the generalisation rule [gen] does not allow us to generalise over the
type variable 'a since it occurs in the behaviour 'a chan {A}; it follows that
5.5 Behaviours 347
[chan] r reA channel71" : T chan {7r} & T chan { 7r}
[spawn]
r reA eo : To & i.po
r reA spawn eo : unit & spawn i.po
[send]
r reA el : T & 'Pl r reA e2 : T chan r2 & 'P2
f reA send e1 on e2: unit & i.p1;i.p2;r2!T
[receive]
r reA eo : T chan ro & i.po
r reA recei ve eo : T & i.po; ro ?T
[seq]
r reA el : TI & 'Pl r reA e2 : T2 & 'P2
f reA e1; e2: T2 & i.p1; i.p2
[ch] r r ch : T chan r & A

CA if T chan r = Î'(ch)
[sub]
r reA e : T & i.p if T :::; T1 and i.p !;;; cp'
f reA e : T 1 & i.p1
[gen]
r reA e : T & i.p
r reA e: V((I, ... ,(n).T & i.p
if (I, · · · , (n do not OCCUI free in f and i.p
[ins]
r reA e: V((I, ... '(n).T & i.p
f reA e : (() T) & i.p
if() has dom(B) ~ {(I,···,(n}
Table 5.17: Communication Analysis (part 2).
ch can "only" be given the type 'a chan {A} and therefore the program fails
to type check (because 'a cannot be equal to int and bool at the same time).
However, if the generalisation rule [gen] were only to require that ( 1 , · · ·, (n
do not occur free in r,
then it would be possible to give the channel ch the
type schema V'a.'a chan {A}; as a consequence we would be able to give types
to the two occurrences of send in the body of the let construct and the type
system would not be semantically correct. •
The rule [sub] for subeffecting and subtyping looks like the one in Table 5.10
but involves a few subtleties. The ordering T :::; T1 on types is given by
T{ ::::: TI ~ ::::: T~ i.p !;;; i.p 1 T:ST' T1 :ST r~r'

TI Î t 72 ::::: 7{ ~ ~ 7 chan r :::; T1 chan r'
'P1 ~ 'P2 'P2 ~ 'P3

'P1 ~ 'P3
'P1 ~ 'P2 'P3 ~ 'P4 'P1 ~ 'P2 'P3 ~ 'P4

'P1; 'P3 ~ 'P2; 'P4 'P1 + 'P3 ~ 'P2 + 'P4
'P1 ~ 'P2
spawn 'P1 ~ spawn 'P2
cp ~A; cp A; cp ~ cp cp ~ cp; A cp;A ~ cp
rec(3.cp ~ cp[(3 t--t rec(3.cp] cp[(3 t--t rec(3.cp] ~ rec(3.cp
75:7' 7'5:7 rr;;,r'

7 chan r ~ 7' chan r'
r1 r;;, r2 71 5: 72 r1 r;;, r2 72 5: 71
r1 !71 ~ r2 !72 r1 ?71 ~ r2 ?72
Table 5.18: Ordering on behaviours.

and is similar to the definition in Subsection 5.4.1: ?) __:e_. 72 is contravariant
in 71 but covariant in cp and 72, and 7 chan r is both covariant in 7 (for
when a value is sent) and contravariant in 7 (for when a value is received)
and it is covariant in r. The ordering r r;;, r' means that r is "a subset of"
of r' (modulo UCAl) just as what was the case for the effects in Section
5.4. Finally, the ordering cp ~ cp' on behaviours in more complex than before
because of the rich structure possessed by behaviours. The definition is given
in Table 5.18 and will be explained below. Since the syntactic categories of
types and behaviours are mutually recursive also the definitions of 7 5: 7'
and cp ~ cp' need to be interpreted recursively.
The axiomatisation of cp ~ cp' in Table 5.18 ensures that we obtain a preorder
that is a congruence with respect to the operations for combining behaviours.
Furthermore, sequencing is an associative operation with A as identity and
we have a distributive law with respect to choice. It follows that choice is
associative and commutative. Next the axioms for recursion allows us to
unfold the rec-construct. The final three rules clarify how behaviours depend
upon types and regions: 7 chan ris both contravariant and covariant in 7 and
is covariant in r (just as was the case for the type 7 chan r); r!f is covariant
in both r and 7 (because a value is sent) whereas r?r is covariant in r and
contravariant in 7 (because a value is received). There is no explicit law for
renaming bound behaviour variables as we shall regard rec(3.<p as being equal
to rec(3' .<p' whenever they are a-equivalent.
The Communication Analysis in Tables 5.16 and 5.17 differs from the Region
Inference Analysis of Tables 5.12 and 5.13 in that there is no analogue of the
rule [region] where an Observe function is used to reduce the annotation to
what is visible from the outside. The reason is that the Communication Anal-
ysis is intended to record all the side effects (in the form of communications)
that take place during computation.
Example 5.37 Returning to the program of Example 5.35 we can now

verify that the node function can be given the type:
('a~ 'b) ~ ('a chan "1) ~ ('b chan "2) ~ unit

where<p=spawn(rec'2. ("1?'a; '1; ''2!'b; '2))
We use the rules [!un] and [sub] of Tables 5.16 and 5.17 together with the
axiom <p[(3 ~ rec(3.<p] !;;:; rec(3.<p of Table 5.18. Then the rule [gen] allows us
to obtain the type schema given in Example 5.35.
Thrning to the pipe function we first note that it can be given a type of the
form
(('a ~ 'a) list) ~ ('a chan (111 U {C} )) ~ ('a chan 112) ~ unit
where the regions for the input and local channels are "merged" because they
can both be used as input channels in a call to pipe whereas the region for
the output channel is always kept separate. The behaviour <p 1 is of the form
rec '2. (spawn(rec '3. (("1 U {C} )?'a; A; "2!'a; '3))

+'a chan C; spawn(rec 14. (("1 U {C} )?'a; '1; C!'a; '4)); '2)
because in the then-branch the input channel for node has type 'a chan ("1 U
{ C}) and the out put channel has type 'a chan 112, whereas in the else-branch
the input channel for node has type 'a chan ("1 U{ C}) and the output channel
has type 'a chan {C} (as well as 'a chan ("1 U { C})). The rule [gen] allows us
to obtain the type schema displayed in Example 5.35. •
Concluding Remarks
Control Flow Analysis. The literature [49, 50, 71, 18] contains many
formulations of non-standard type systems aiming at performing Control
Flow Analysis. The formulation presented in Section 5.1 uses a particularly

simple set of techniques where types are annotated but there is no additional
effect component nor is there any coverage of polymorphism or subtyping.
Although there is no explicit clause for subeffecting in the manner of Section
5.4, we regard the formulation as a subeffecting analysis because the rules
for function abstraction allow us to increase the annotation on the function
arrow in much the same way as is the case in subeffecting (and in much more
restricted ways than holds for subtyping; see also Exercise 5.13). References
for type systems with subtyping include [59, 58, 107] as well as the more ad-
vanced [83, 160, 161] that also deal with polymorphism. To allow a general
treatment of subtyping, these papers generally demand constraints to be an
explicit part of the inference system unlike what was done in Section 5.1. In-
deed, the formulation of Section 5.1 allows only shape conformant subtyping,
where the underlying type system does not make use of any form of subtyp-
ing, and is thus somewhat simpler than atomic subtyping, where an ordering
is imposed upon base types, and general subtyping, where an ordering may
be imposed between arbitrary types.
The semantic correctness of the Control Flow Analysis established in Section
5.2 is expressed as a subject reduction result but formulated for a Natural Se-
mantics [91] (rather than a Structural Operational Semantics); this approach
to semantic correctness has a rather long history [114, 116, 184]. The Moore
family result about the set of typings is inspired by the ideas of [114] and is
included so as to stress the fundamental role played by partial orders in all
of the approaches to program analysis considered in this book; it also relates
to the study of principal types in type systems.
The development of a syntactically sound and complete algorithm for the
Control Flow Analysis in Section 5.3 is based on the ideas in [90, 183, 167,
168, 169]; the call-tracking analysis of Mini Project 5.1 is based on [169].
The basic idea is to ensure that the algorithm operates on a free algebra by
restricting annotations to be annotation variables only (the concept of simple
types) and by recording a set of constraints for the meaning of the annotation
variables; in our case this is particularly straightforward because the Control
Flow Analysis does not deal with polymorphism. Our development differs
somewhat from that of [58, 107] that deal with the more advanced notions of
atomic subtyping and general subtyping. A different approach, not studied
here, would be to dispense with simple types and constraints and instead use
techniques for unifying types in a non-free algebra [159].
Restricted effects. The Type and Effect Systems presented in Sec-

tion 5.4 all share the important property (also holding for the type system
in Section 5.1) that no type information is recorded in the effects and that
the shape of the type information cannot be infiuenced by the effects. All
systems included a proper effect component and thereby illustrated the di-
versity of effects; some pioneering papers in Type and Effect Systems are
[88, 102, 89, 90]. At the same time we illustrated a number of design consid-
erations tobe taken into account when devising a Type and Effect System:
whether or not to incorporate subeffecting, subtyping, polymorphism, poly-
morphic recursion, whether or not types are allowed to be influenced by
effects (which is not the case in Sections 5.4 and 5.1), and whether or not
constraints are an explicit part of the inference system (as is implicitly the
case in Subsection 5.4.3). However, it would be incorrect to surmise that the
selection of components are inherently linked to the example analysis where
they were illustrated. Rather, the techniques needed for semantic correctness
and for syntactic soundness and completeness depend heavily on the partic-
ular selection of components; some are straightforward to deal with whereas
others are beyond state-of-the-art.
The Side Effect Analysis presented in Subsection 5.4.1 illustrated the use
of subeffecting and subtyping, but did not incorporate polymorphism, there
were no constraints in the inference system, and the effects did not influence
the types. This system is sufficiently simple that semantic soundness may
be established using the techniques of Section 5.2. If the rule for subtyping
was omitted then also the techniques developed in Section 5.3 would suffice
for obtaining a sound and complete inference algorithm. The presence of
the rule for subtyping naturally leads to a two stage implementation process:
first the underlying types are inferred and next the constraints on effects
(or annotations) are determined [169, 174]. This works because we restrict
ourselves to shape conformant subtyping where effects do not infiuence the
type information. However, adding polymorphism to this development would
dramatically increase the complexity of the development (see below).
The Exception Analysis presented in Subsection 5.4.2 illustrated the use of
subeffecting, subtyping and polymorphism, but there were no constraints in
the inference system, and the effects did not infl.uence the types. Semantic
soundness is a bit more complex than in Section 5.2 because of the polymor-
phism but the techniques of [173, 167, 168, 15] suffice. For the development
of a syntactically sound and complete inference algorithm one may take the
two stage approach described above [169, 174]; as before, it works because
we restrict ourselves to shape conformant subtyping where effects do not
influence the type information. Alternatively, one may use more powerful
techniques [183, 167, 168, 127] that even allow to include type information
inside effects; this amounts to an extension of the approach of Section 5.3
and will be explained below.
The Region lnference analysis presented in Subsection 5.4.3 illustrated the
use of polymorphic recursion as far as the effects are concerned, there were
implicitly constraints in the inference system (via the dot notation on func-
tion arrows), but still the effects cannot influence the types. The presentation
is mainly based on [175] but adapted to the FUN language and the style of
presentation used elsewhere in this chapter. To obtain effects that are as
small as possible the inference system uses "effect masking" (developed in

[102, 167, 168]) for removing internal components of the effect: effect com-
ponents that only deal with regions that are not externally visible. Semantic
correctness of the inference system can be shown using the approach of [176].
For the development of a syntactically sound inference algorithm one may
once more take the two stage approach described above; the first stage (or-
dinary type inference) is standard and the second stage is considered in [17 4]
where algorithm S generates effect and region variables and algorithm R
deals with the complications due to polymorphic recursion (for effects and
regions only). The inference algorithm is proved syntactically sound but is
known not tobe syntactically complete; indeed, obtaining an algorithm that
is syntactically sound as well as complete, seems beyond state-of-the-art.
General effects. One way to make effects more expressive is to allow

type information inside the effects so that the shape of the type information
can be infiuenced by the effects. This idea occurred already in [183, 167, 168]
for an extended Side Effect Analysis making use of polymorphism and subef-
fecting (but not subtyping); this work attempted to "generalise" previous
work based on the idea of expansive expressions and imperative versus ap-
plicative type variables [173, 166]. As already indicated, semantic soundness
amounts to an extension of the techniques of Section 5.2 as presented in
[173, 167, 168, 15].
The two stage approach no longer works for obtaining an inference algorithm
because the effects are used to control the shape of the underlying types
in the form of which type variables are included in a polymorphic type.
This suggests extending the techniques of Section 5.3 in that special care
needs to be taken when deciding the variables over which to generalise when
constructing a polymorphic type. The main idea is that the algorithm needs
to consult the constraints in order to determine a larger set of forbidden
variables than those directly occurring in the type environment or the effect;
this can be formulated as a downwards closure with respect to the constraint
set [183, 127] or by taking a principal solution of the constraints into account
[167, 168].
Adding subtyping to this development dramatically increases the complexity
of the development. The integration of shape conformant subtyping, poly-
morphism and subeffecting is done in [127, 134, 15] that establishes semantic
soundness and develops an inference algorithm that is proved syntactically
sound; extensions of this development incorporate a syntactic completeness
result (see the discussion of [13] below). This work went a long way to-
wards integrating the techniques for polymorphism and subeffecting (but no
subtyping) from Effect Systems [183, 167, 168] with the techniques for poly-
morphism and subtyping (but no effects) from Type Systems [83, 160, 161].
Another way to make effects more expressive is to let them contain infor-
mation about the temporal order and causality of actions, rather than just
Mini Projects 353
being an unordered set of possibilities. In Section 5.5 we considered the task

of extracting behaviours (reminiscent of terms in a process algebra) from
programs in Concurrent ML by means of a Type and Effect System; here
effects (the behaviours) have structure, they may influence the type informa-
tion, there are no explicit constraints in the inference system (although there
are in more advanced developments [13]), and there are inference rules for
subeffecting and shape conformant subtyping. These ideas first occurred in
[119, 120] (not involving polymorphism) and in [131, 132, 14] (involving poly-
morphism); our presentation in Section 5.5 is mainly based on [131, 132] with
ingredients from [119, 120]. We refer to [13] for a comprehensive account of a
more ambitious development where the inference system is massaged so as to
facilitate developing a syntactically sound and complete inference algorithm;
this includes having explicit constraints in the inference system as is usually
the case in type systems that make use of subtyping. An application to the
validation of embedded systems is presented in [128].
Other developments. Ali of the formulations presented in this chap-

ter have had a number of common features: to the extent that polymorphism
has been incorporated it has been based on the Hindley /Milner polymor-
phism also found in Standard ML, there has been no subtyping involved in
the underlying type system, and there has been no treatment of conjunction
or disjunction types as in [19, 20, 81, 82]. Also ali of the formulations have
expressed safety properties: if a certain point is reached then certain infor-
mation will hold; liveness properties in the form of adding annotations that
indicate whether or not functions can be assumed to be total was considered
in [121].
Finally, linking up with the development of Chapter 4 on Abstract Interpre-
tation, it is possible to allow annotations to be elements of a complete lattice
(that is possibly of finite height as in Monotone Frameworks) as outlined in
Mini Project 5.4; s this mini project also discusses how to deal with binding
time analyses (inpired by [75, 114, 123]) and security analyses (inspired by
[74, 1]). In the other direction it may be profitable to describe Type and
Effect Systems using the framework of Abstract Interpretation [108, 36].
Mini Project 5.5 on units and the year 2000 problem (Y2K) was inspired by
[95, 46, 141].
Mini Projects
Mini Project 5.1 A Call-Tracking Analysis
Consider a Type and Effect System for Call-Tracking Analysis: it has judge-
ments of the form
r f--cT e: T & cp
where cp denotes the set of functions that may be called during the evaluation
of e (and similarly for the annotations on function arrows).
1. Formulate an inference system with subeffecting; next add subtyping

and finally add polymorphism.
Next consider the inference system with subeffecting only:
2. Modify the Natural Semantics of Table 5.4 such that semantic correct-
ness can be stated for the analysis and prove that the result holds.
3. Devise an algorithm for Call-Tracking Analysis and prove that it is
syntactically sound (and complete).
For the more ambitious: can you also deal with subtyping and/or polymor-
phism? •
Mini Project 5.2 Data Structures
As in Mini Project 3.2 we shall now extend the language with more general
data structures and consider how to modify the Control Flow Analysis (Table
5.2) so as to track the creation points.
Pairs. To accommodate pairs we extend the syntax as follows:

r .. - .. · r1
1 x'P r2
e .. - · ··1 Pair1r(e1,e2) 1(case eo of Pair(x1,x2) => e1)
Here Pair is a binary constructor and the corresponding case-expression does
not need an or-component as in Mini Project 3.2. As an example, consider
the following program for "sorting" a pair of integers:
let srt = fnx x => case x of Pair (y, z) =>
if y<z then x else Pair 8 (z,y)
in srt(PairA(n,m))
Here the pair returned with be constructed at A if the value of n is smaller

than the value of m and at B otherwise. The overall type is int x {A,B} int.
1. Modify the Control Flow Analysis of Table 5.2 to track the creation
points of pairs.
2. Extend the Natural Semantics of Table 5.4 and augment the proof of
semantic correctness (Theorem 5.9).
3. Extend the algorithms WcFA and UcFA and augment the proof of syn-
tactic soundness and completeness (Theorems 5.20 and 5.21).
Mini Projects 355
Lists. To accommodate lists we extend the syntax as follows:

7 .. - · · · 1 7 list"'
e .. - · · ·1 Cons1r(e1,e2) 1 Nil1r 1 (case eo of Cons(x1,x2) => e1 or e2)
Now perform a similar development as the one you performed for pairs.
For the more ambitious: can you give a more general treatment of algebraic
types in the manner of Mini Project 3.2? •
Mini Project 5.3 A Prototype Implementation
In this mini project we shall implement the Control Flow Analysis consid-
ered in Sections 5.1 and 5.3. As implementation language we shall choose a
functional language such as Standard ML or Haskell. We can then define a
suitable data type for FuN expressions as follows:
type var string

type point int
datatype const = Num of int 1 True 1 False
datatype exp Const of const 1 Var of var 1 Fn of point * var * exp
Fun of point * var * var * exp 1 App of exp * exp
lf of exp * exp * exp 1 Let of var * exp * exp
Op of string * exp * exp
1. Define data types for simple types and simple substitutions and imple-
ment the function UcFA of Table 5.7.
2. Define data types for simple type environments and constraint sets and
implement the function WcFA of Table 5.8.
3. Define data types for types and type environments and implement a
function that pretty prints the result in the manner of Subsection 5.3.4:
type variables must get instantiated to int and annotation variables to
the least solution to the constraints.
Test your implementation on selected examples. •

Mini Project 5.4 Monotone Type Systems
Consider an instance of a monotone structure as defined in Subsection 3.5.2

(and motivated by the Monotone Frameworks of Section 2.3); examples in-
clude the Constant Propagation Analysis of Example 3.29.
Define an Annotated Type System with subeffecting (and possibly subtyp-

ing) for performing the analysis specified by the monotone structure (in the
manner of the annotated base types of Table 1.2). Design the system such
that it becomes possible to specify the following analyses:
• A binding time analysis where data can be static (i.e. available at

compile-time) or dynamic (i.e. available at run-time), denoted S and
D, respectively. Define a partial ordering by setting S !;;;; D to indicate
that static data can also be used for operating upon dynamic data.
• A security analysis where data can be classified at several clearance
levels Ct, · · ·, Ck. Definea partial ordering by setting C1 !;;;; • • • !;;;; Ck to
indicate that data at low levels of clearance can also be used at high
levels of clearance.
How much of the development in Sections 5.2 and 5.3 can be adapted to
this scenario? (Feel free to impose further conditions if needed, e.g. that the
.
property space satisfies the Ascending Chain Condition.)
For the more ambitious: can you deal with both subtyping and polymor-
~~
Mini Project 5.5 Units of Measure (and Y2K)
Even the most advanced programming languages, allowing user defined data
types and enforcing strong typing, hardly ever record units of measure (for
example meters, degrees Centigrade, US dollars). Each unit of measure may
involve two ingredients: the scaling factor and the base of origin:
• An example of different scaling factors concerns the measure of length

which can be measured in feet (FT) or in meters (M); in this case there
is a simple conversion between the two units: x FT = (x * 0.3048)
M. A related example concerns the measure of currency which can be
measured in US dollars (USD) or European currency units (EURO);
here the conversion is slightly more complex: x USD = (x *rate) EURO
where rate is the exchange rate which is likely to vary over time.
• An example of different bases of origins concerns the measure of time

which can be measured relative to the birth of Christ (AD) or relative to
the beginning of the 20'th Century (YY); there is a simple conversion:
x YY = (1900 + x) AD. The so-called year 2000 problem (Y2K) arises
when there are only two digits available for x and one needs to represent
a year that is not in the 20'th Century.
• An example of a measure involving both ingredients is the measure of
temperature which can be measured in degrees Fahrenheit (F) and de-
Mini Projects 357
grees Centigrade (C); in this case the conversion between temperatures

is more complex: x F = ((x- 32) * 5)/9 C.
There are many reasons for why one would like to extend the programming
language to be precise about the units of measurement; perhaps one needs
to port the software to a new environment where a different unit of mea-
surement is used, perhaps one is operating on data presented in a mixture of
units of measurement, perhaps one wants to reduce the likelihood of inear-
rect computations (like adding US dollars and European currency units), or
perhaps one wants to prepare for a change in data formats.
Let us assume that we are given a program that is correctly typed in some un-
derlying type system. One approach to incorporating units into the program
proceeds as follows:
1. The type system is extended to include unit annotations on numbers.
2. The program is analysed according to the extended type system; most

likely a number of type errors are identified.
3. The type errors are corrected by inserting explicit conversion functions

based on the above discussion.
4. It is checked that the resulting program is type correct in the extended

type system.
5. Possibly data formats are changed based on the extended type infor-
mation.
In this mini project we focus on the first task and for our purposes it suffices
to let the syntax of the underlying types be given by:
7 ::= num 1 7 -t 7
A suitable extended type system might be based around the following types
and annotations:
f .. - num'f' 1 f -t f
cp ··- scale BASE base
scale unit 1 scale.scale 1 scale- 1 1
(]" 1
feet 1 meter 1 usd 1 euro 1 year 1 kelvin 1 · · ·
base f3 1 none 1 ad 1 20th 1 freezing 1 · · ·

We model meters (M) as meterBASEnone and feet (FT) as feetBASEnone;
US dollars (USD) as usdBASEnone and European currency units (EURO) as
euroBASEnone; years relative to the birth of Christ (AD) as yearBASEad
and years relative to the 20'th Century (YY) as year BASE 20th; degrees
Centigrade (C) as kelvinBASEfreezing etc. "Ordinary'' numbers without

units now have the annotation unit BASE none.
One way to associate units with numbers is to use functions like
ase: numunitBASEnone ---t numkelvinBASEfreezing
so that ase 7 denotes 7 degrees Centigrade. To compute with numbers

having units we shall give the arithmetic operations for multiplication and
division the following polymorphic types:
* V'a1,a2,a[with a= a1.a2]:
numu1 BASEnone ---t numu2 BASEnone ---t numuBASEnone
1 V'a1,a2,a[with a= ada2 1)]:

numu1 BASEnone ---t numu2 BASEnone ---t numuBASEnone
This reflects the fact that multiplication and division works on relative units
of measurement (i.e. having no base). One needs tobe careful about the the
laws imposed upon annotations so as to ensure that e.g. meter.feet is treated
in the same way as feet.meter in accordance with the usual conventions of
Physics; this amounts to an axiomatisation that is more refined than the
UCAl axiomatisation.
Thrning to the operations for addition and substraction:
+ .
V'a, /31, /32, f3 [w1th f3 =
{ (3fJ1 if /32 = none ]
2 1'f (3 1 = none
l
numu BASE /31 ---t numu BASE {32 ---t numu BASE {3
'ia,/31,/32,/3 [with f3 = { ~~ne

undefined
if /32 = none
if /31 = !32
otherwise
numu BASE {31 ---t numu BASE {32 ---t numu BASE {3
This reflects the fact that addition can be used on units of measurement
where at most one has a base and that subtraction can be used to find the
relative unit of measurement between two based measurements as well as to
decrease a based measurement by a relative unit.
Define an annotated type system for a version of the FUN language using
a selection of the ideas above. It may be helpful to allow polymorphism
only for the scale annotations (using the scale variables a) and the base
annotations (using the base variables (3). Try to establish a notion of semantic
correctness for the annotated type system. Develop an inference algorithm
and prove it syntactically sound. Finally investigate whether or not the
inference algorithm is syntactically complete.
Exercises 359
In some cases it is possible to extend this scheme with explicit rules for
conversion between units; e.g. x FT = x * 30.48 CM which involves both a
conversion between feet (FT) and meters (M) and between meters (M) and
centimeters (CM). This is not always feasible (e.g. in the case of currency)
and we shall leave the extension to the interested reader. •
Exercises
Exercise 5.1 Consider the following expression:
let f = fnx x => x 1;
g = fnv y => y+2;
h = fnz z => z+3
in (f g) + (f h)
Use Table 5.1 (the underlying type system) to obtain a type for this expres-
sion; what types do you use for f, g and h? Next use Table 5.2 (Control Flow
Analysis) to obtain the annotated type of this expression; what annotated
types do you use for f, g and h? •
Exercise 5.2 Consider the following variation of FUN where function def-
initions explicitly involve type information as in fn1r x : 7x => eo and fun1l" f :
(7x ~ 7o) x => eo. Modify Table 5.1 accordingly and prove that the resulting
type system is deterministic: r f-uL e : 71 and r 1-uL e : 72 imply 71 = 72. •
Exercise 5.3 Consider the inclusion 'Pl ~ 'P 2 between effects that was
discussed in Subsections 5.4.1 and 5.2.3. Give an axiomatisation of 'Pl ~ 'P 2
such that 'Pl ~ 'P2 holds if and only if the set of elements mentioned in 'Pl is
a subset of the set of elements mentioned in 'P2· •
Exercise* 5.4 In Example 5.4 we showed how to record the annotated

type information in a form close to that considered in Chapter 3. To make
this precise suppose that expressions of FuN are simultaneously labelled as
in Chapters 3 and 5:
e .. - te
t .. - c 1 x 1 fn1r x => eo 1 fun1r f x => eo 1 e1 e2
i f eo then e1 else e2 llet x = e1 in e2 1 e1 op e2
Next modify Table 5.2 so as to definea judgement

p, C; r 1-cFA e : T (5.2)
where the idea is that
• C(f) = 7l ensures that all judgements p, C; r' 1--cFA tl : T' in (5.2) have
T' = 7l, and
• p(x) = 7x ensures that all judgements p, C;
~, ~
r' 1--cFA xl : 7' in (5.2) have
7 = 7x.
Check that (5.2) holds for the expression in Example 5.4 when we take C(1) =
rv, C(2) = rv {x} rv,
C(3) = int, C(4) = C(5) = p(x) = rv,
and rv, rv
p(y) = int. •
Exercise 5.5 Consider adding the following inference rule to Table 5.2
(Control Flow Analysis)
r 1--cFA el ~: 72 ..2..t 7o r 1--cFA e2 : 72 .

d~=
0
r 1--cFA e1 e2 : l_~
ro
where 1_;-o is the least element of TYPe[7o] and 7o = l7oJ. Explain what this
rule does and determine whether or not Theorem 5.9 (semantic correctness)
continues to hold. •
Exercise 5.6 We shall now extend the Control Flow Analysis of Section
5.1 to include information about where functions are called. To do so modify
the syntax of expressions by adding labels to all application points (in the
manner of Chapter 3):
e ::= · · · 1 (el e2/
Also define a syntactic category of labei annotations 1/J E LAnn by
tobe interpreted modulo UCAl. Finally modify the syntax of annotated types
as follows:
7~ ::= · · · 1 71
~ </> ~
----t 72
'ljJ
In this system it should be possible to type the expression
((fnx x => x) (fny y => y)) 1
(see Example 5.4) such that fnx x => x gets the type
(int 22.
0
int) ~ ( int
{1}
22.
0
int)
indicating that it is called at the application labelled 1; more generally it

should have the type
(T {Y}U</>v 7) {X}U</>x (T {Y}U</>v 7)
'1/Jv {l}U'I/Jx 'ljJy
for all c/Jx, cf>y E Ann, 1/Jx, 1/Jy E LAnn, and 7 E TYPe. Modify the analysis
of Table 5.2 so as to specify this analysis. •
Exercises 361
Exercise 5. 7 In Section 5.2 we equipped FuN with a call-by-value se-

mantics. An alternative would be to use a call-by-name semantics. It can be
obtained as a simple modification of the semantics of Table 5.4 by changing
rule [app] such that the argument is not evaluated before the substitution
takes place and similarly changing rule [let]. Make these changes to Table 5.4
and show that the correctness result (Theorem 5.9) stiH holds for the analysis
of Table 5.2.
What does that tell us about the precision of the analysis? •
Exercise 5.8 Prove Fact 5.17 (the syntactic soundness and completeness
of Robinson unification). •
Exercise 5.9 Consider the partial ordering f s T' on the annotated types
of Section 5.1 that is defined by:
7{sf1 f2s~ cpc;;cp'
......... c.o_ .-. --::::::1 (/)'_ -:::::1
71 --'-t 72 s 71 --'--t 72
We shall say that this ordering treats 7) -'1!...; ~ covariantly in <p and f2 but
contravariantly in 7); this is in line with the subtype ordering considered in
Section 5.4 but differs form the partial ordering f!;;; f' considered in Section
5.2.
Show that (TYPe[7], s) is a complete lattice for all choices of the underlying
type 7 E Type. Next investigate whether or not an analogue of Proposition
5.12 holds for this ordering.
Finally reconsider the decision to let ()~(o:) in Subsection 5.3.4 be the least
element of (TYPe[7], !;;;); would it be preferable to let ()~(o:) be the least
element of (Type[7J, s) or (TYPe[7J, ~)? •
Exercise* 5.10 Suppose that

WuL([ ], funF f x => eo) = (o:x----+ o:o, B)
where O:x and o:o are distinct type variables. Let e be an arbitrary correctly
typed closed expression, i.e. [ ]1-uL e : 7 for some 7 and show that the call
(funF f x => eo) e

cannot terminate. (Hint: use Fact 5.6, Theorems 5.9, 5.20 and 5.21 and that
WuL is syntactically sound.) •
Exercise 5.11 Formulate what it means for the Side Effect Analysis of
Table 5.9 to be semantically correct; this involves modifying the Natural
Semantics of Table 5.4 to deal with the store and to record the side effects.
(Proving the result would require quite some work.) •
Exercise 5.12 Suppose that the language of Subsection 5.4.1 has a call-
by-name semantics rather than a call-by-value semantics. Modify the Side
Effect Analysis of Table 5.9 accordingly. •
Exercise 5.13 We shall now illustrate the concept of proof normalisation

for the Side Effect Analysis of Subsection 5.4.1; for this we shall assume that
Table 5.9 does not include the combined rule for subeffecting and subtyping
but only the rule for subeffecting.
For this system one can dispense with an explicit rule for subeffecting by
integrating its effects into all other rules; this can be done by adding a "Ucp"'
to all effects occurring in the conclusions of all axioms and rules. Do this and
argue that exactly the same judgements are provable in the two systems.
A further variation is only to incorporate "Ucp'" where it is really needed: in
all axioms and in the rules for function abstraction. Do this and argue that
once more exactly the same judgements are provable in the two systems.
What you have performed amounts to proof normalisation: whenever one
has an inference system with a number of syntax directed rules and axioms
and at least one rule that is not syntax directed, it is frequently possible to
restrict the use of the non syntax directed rules. In this way the structure
of the inference trees comes closer to the structure of the syntax trees and
this is often helpful for proving semantic correctness and is a useful starting
point for developing inference algorithms. •
Exercise 5.14 Consider the rule [handle] in the Exception Analysis of

Table 5.10. Would the analysis stiU be semantically correct if we replaced it
by the following two rules:
r f-Es el : T & 'Pl r f-Es e2 : T & 'P2

r f-Es handle s as el in e2 : T & 'P2
if s (/. C,02 and A V (C,02) = 0
r f-Es el : T & 'Pl r f-Es e2 : T & 'P2

r f-Es handle sas el in e2: T & 'Pl u (cp2\{s})
if s E C,02 or A V (C,02) =/:- 0
Here s E C,02 means {s} ~ <p2 and A V (<p2) is the set of annotation variables
in 'P2· •
Exercise 5.15 Consider the Exception Analysis of Table 5.10 and change
the rule [let] to
f f-Es e1 : â1 & C,Ol f[x f-t â1] f-Es e2 : â2 & C,02

f f-Es let X = e1 in e2 : â2 & 'Pl U C,02
Exercises 363
and perform similar changes in [i~, [raise], [hand le] and [sub]; do not forget to
define the meaning of 7 ~ T'. Clearly the new system is at least as powerful
as Table 5.10 but is it more powerful? (Hint: Consider the places where [gen]
and [ins] can be used in Table 5.10.) •
Chapter 6
Algorithms
In previous chapters we have studied several algorithms for obtaining solu-

tions of program analyses. In this chapter we shall explore further the sim-
ilarities between the different approaches to program analysis by studying
general algorithms for solving equation or inequation systems.
6.1 Worklist Algorithms

We will abstract away from the details of a particular analysis by considering
equations or inequations in a set of ftow variables for which we want to
salve the system. As an illustration, in Data Flow Analysis there might be
separate flow variables for the entry and exit values at each program point,
whilst in Constraint Based Analysis there would be a separate flow variable
for the cache at each program point and for the environment at each program
variable.
Example 6.1 Consider the following WHILE program

i f [b1Jl then (while [b2j2 do [x := a1j3)
else (while [b3] 4 do [x := a2] 5 );
[x := a3] 6
where we leave the expressions ai and bi unspecified. The equations generated
by the Reaching Definitions Analysis of Section 2.1.2 take the form:
RDentry(l) =X? RDexit(l) = RDentry(l)
RDentry(2) = RDexit(l) U RDexit(3) RDexit(2) = RDentry(2)
RDentry(3) = RDexit(2) RDexit(3) = (RDentry(3)\X356?) UX3
RDentry(4) = RDexit(l) U RDexit(5) RDexit(4) = RDentry(4)
RDentry(5) = RDexit(4) RDexit(5) = (RDentry(5)\X356?) U X5
RDentry(6) = RDexit(2) U RDexit(4) RDexit(6) = (RDentry(6)\X356?) U X6
366 6 Algorithms
Here Xt = { (x, l)} and we also allow a string of subscripts on X; for example,
x356? = {(x, 3), (x, 5), (x, 6), (x, ?)}.
When expressed as a constraint system in the flow variables {X1, · · • , x12 } it

takes the form
X1 X? X7 = Xl
X2 = X7 Uxg Xg X2
X3 Xg Xg (x3 \X356?) U X3
X4 = X7 U Xu XlQ X4
X5 = XlQ xu (x5 \X356?) U X5
X6 Xg U XlQ X12 (x6 \X356?) U X6
where x1, · · · , x6 correspond to RD entry (1), · · · , RD entry ( 6) and X7, · · · , X12 cor-
respond to RDexit(l), · · ·, RDexit(6).
Since we are generally interested in the solution for RD entry, we shall in this
and subsequent examples consider the following simplified equation system:
X1 = X?
X2 = Xl u (x3 \X356?) u x3
X3 X2
X4 = Xl u (x5 \X356?) u x5
X5 X4
X6 x2 Ux4
Clearly nothing is lost by these changes in representation. •

Equations versus inequations. An apparent difference between
the settings of Chapters 2 and 3 is that we solve equation systems (xi = ti)~ 1
in the former but inequation systems (xi ;;;) ti)~ 1 in the latter. However, al-
ready in Section 2.2, we observed that a solution of an equation system is also
a solution of the inequation system resulting from replacing all occurrences
of"=" by ";;;!". In fact, the following inequation system (where allleft hand
sides are the same)
and the equation

= X U t1 U · · · U tn
X
have the same solutions: any solution of the former is also a solution of the
latter and vice versa. Furthermore, the least solution of the above systems is
also the least solution of
x=hU···Utn
(where the x component has been removed on the right hand side). Given
these observations, it should be clear that it does not much matter whether
our algorithms are supposed to salve inequation or equation systems - but see
Exercise 6.5 for the flexibility of inequation systems in obtaining efficient al-
gorithms. Throughout this chapter we will concentrate on constraint systems
with multiple inequations for the same left hand side.
6.1 Worklist Algorithms 367
Assumptions. We make the following assumptions:
• There is a finite constraint system S of the form
for N ~ 1 where the left hand sides are not necessarily distinct.
• The set FV(ti) of flow variables contained in a right hand side ti is a

subset of the finite set X = { Xi 1 1 :S i :S N}.
• A solution is a total function, 'ljJ : X --+ L, assigning each flow variable

a value in the complete lattice (L, ~) satisfying the Ascending Chain
Condition.
• The terms are interpreted with respect to solutions, 'ljJ : X --+ L, and
we write [t]'lj; E L to represent the interpretation of t with respect to
'lj;.
• The interpretation [t]'lj; of a term t is monotone in 'ljJ and its value only
depends on the values {'lj;(x) 1 x E FV(t)} of the solution on the flow
variables occurring in the term.
In the interest of generality, we leave the nature of the right hand sides, ti,
unspecified.
Example 6.2 The constraints used in this chapter may appear tobe sim-
pler than those used in Chapter 3 in that apparently we do not allow con-
ditiona} constraints. However, conditiona} constraints can be dealt with by
allowing the terms to contain conditionals. Consider the following expression
(from Example 3.20):
Using the notation above, the constraints generated by the Constraint Based
0-CFA Analysis are:
X1 2 Xfi x2 2 {fn x => x 1 }

X3 2 X7 X4 2 {fn y => y3 }
X5 2 if { fn x => x 1 } ~ x2 then x1 x5 2 if {fn y => y 3 } ~ x2 then x3
X6 2 if { fn x => x 1 } ~ x2 then X4 x7 2 if {fn y => y 3 } ~ x2 then x4
Here x1 to X5 correspond to C(l) to C(5), X6 corresponds to r(x) and x7

corresponds to r(y). •
368 6 Algorithms
6.1.1 The Structure of Worklist Algorithms

In Chapters 2 and 3, we already presented algorithms for solving the sys-
tems which arise from Intraprocedural Data Flow Analysis and Control Flow
Analysis. The common feature of those algorithms is that they both use a
worklist to control the iteration. Some representation of the work to be dane
is stored in the worklist; the iteration selects a task from the worklist and
removes it - the processing of the task may cause new tasks to be added to
the worklist. This process is iterated until there is no more work to be dane
- the worklist is empty.
Operations on worklists. Our starting point in this section is an

abstract variant of those previous algorithms. It is abstract because it is
parameterised on the details of the worklist and on the associated operations
and values:
• empty is the empty worklist;

• insert((x;;;;:) t),W) returns a new worklist that is as W except that a new
constraint x ; ; :) t has been added; it is normally used as in
W := insert((x;;;;:) t),W)
so as to update the worklist W to contain the new constraint x ; ; :) t;
• extract(W) returns a pair whose first component is a constraint x ; ; :) t
in the worklist and whose second component is the smaller worklist
obtained by removing an occurrence of x;;;;:) t; it is normally used as in
((x;;;;:) t),W) := extract(W)
so as to select and remove a constraint from W.
In its most abstract form the worklist could be viewed as a set of constraints
with the following operations:
empty = 0
function insert((x;;;;:) t),W)
return WU {x;;;;:) t}
function extract(W)
return ((x;;;;:) t),W\{x;;;;:) t}) for some x;;;;:) tin W
However, it may be more appropriate to regard the worklist as a multiset

(thereby allowing constraints to occur more than once on the worklist), as
a list with additional structure, or as a combination of other structures; the
structure will be used by the function extract to extract the appropriate
constraint. Later in this chapter we shall illustrate how a judicious choice
INPUT: A system S of constraints: Xt ;;;;) it,···, XN ;;;;) tN
OUTPUT: The least solution: Analysis
METHOD: Step 1: Initialisation (of W, Analysis and infl)

W := empty;
for ali x ;;;;) t in S do
W := insert((x;;;;) t),W)
Analysis[x] := ..l;
infl[x] := 0;
for ali x ;;;;) t in S do
for ali x' in FV(t) do
infl[x'] := infl[x'] U {x;;;;) t};
Step 2: Iteration (updating W and Analysis)
while W -::j:. empty do
((x;;;;) t),W) := extract(W);
new := eval{t,Analysis);
if Analysis[x] :il new then
Analysis[x] := Analysis[x] U new;
for ali x' ;;;;) t' in infl[x] do
W := insert{(x';;;;) t'),W);
USING: function eval{t,Analysis)

return [t](Analysis)
value empty
function insert((x;;;;) t),W)
return · · ·
function extract(W)
return · · ·
Table 6.1: The Abstract Worklist Algorithm.
of "structure" will produce worklist algorithms with good practica! perfor-

mance.
Abstract worklist algorithm. The abstract worklist algorithm is

shown in Table 6.1. Since the solution is a function with finite domain,
we have represented it as an array, Analysis, as we did in Section 2.4. The
algorithm uses a worklist, W, and an auxiliary array of sets of constraints,
infl, that records the constraints whose values are infiuenced by a given flow
variable; after step 1 we have for each x in X:
infl[x] = {(x' ;;;;) t') inS 1 x E FV(t')}

370 6 Algorithms
Initially the worklist contains ali constraints from S, the influence sets are
generated and the Analysis array has every flow variable set to .l. During
the iteration a constraint x ; ; ;) t is selected from the worklist using the extract
function. If the Analysis array is assigned during the iteration, ali constraints
influenced by the updated variable are added to the worklist using the insert
function. The algorithm terminates when the worklist equals the value empty.
Example 6.3 Consider the simplified equation system from Example 6.1.
After step 1 of the abstract worklist algorithm of Table 6.1, the worklist W
contains ali equations and the influence sets are as foliows (where we identify
the equations with the flow variables on the left hand side):
X1 X2 X3 X4 X5 X6
infl {x2,x4} {x3,x6} {x2} {x5,x6} {x4} 0
Additionaliy Analysis is set to 0 for ali flow variables. We shali continue this
example later. •
Properties of the algorithm. Despite the abstract presentation of

the algorithm we can give a proof of its correctness and an upper bound on its
complexity that will remain true even when more specialised representations
of the worklist are used.
Given a system of constraints, S = (xi ;;;:) ti)~ 1 , we define a function
Fs: (X---+ L)---+ (X---+ L)
by:
Fs('l/J)(x) = UHt]'I/J 1 x;;;;;) tin S}
This defines a monotone function over the complete lattice X ---+ L and it
foliows from Tarski's Fixed Point Theorem (see Proposition A.10) that Fs
has a least fixed point, J.Ls, which is the least solution to the constraints S.
Since L by assumption satisfies the Ascending Chain Condition and since X
is finite it foliows that also X ---+ L satisfies the Ascending Chain Condition;
therefore J.Ls is given by
J.Ls = lfp(Fs) = UF~(.l)

j~O
and the chain (F.5(.l))n eventually stabilises.
Lemma 6.4 Given the assumptions, the algorithm of Table 6.1 computes
the least solution of the given constraint system, S. •
Proof We write Analysisi[x] to represent the value of Analysis[x] after the i-th
iteration of the loop considered.
First we prove termination. The loops in step 1 are ali for-loops; thus termination
of step 1 is trivialiy proved. The body of the while-loop of step 2 removes an
element from the worklist, it then either adds at most N elements to the worklist
(if Analysis[x] is assigned to) or else it leaves the worklist unchanged (if Analysis[x]
is not assigned to ). If Analysis[x] is assigned to it gets a strictly larger value. Since
L satisfies the Ascending Chain Condition, Analysis[x] (for each of the finitely many
x E X) can only change a finite number of times. Thus the worklist will eventualiy
be exhausted.
The correctness proof is in three parts: (i) first we show that on each iteration the
values in Analysis are less than or equal to the corresponding values of J.Ls, (ii) then
we show that J.Ls is less than or equal to Analysis at the termination of step 2, and
(iii) finaliy we combine these results.
Part (i). We show that
Vx E X: Analysisi[x] G J.Ls(x)
is an invariant of the while-loop of step 2: After step 1 the invariant is trivialiy

established. We have to show that the while-loop preserves the invariant. For each
iteration of the while-loop, either there is no assignment or else for some constraint
x ;:;:1 t inS, we perform an assignment to Analysis[x] so that:
Analysisi+dx] Analysisi [x] U eval(t, Analysis;)

Analysisi [x] U [t](Analysis;)
C::: J.Ls(x) U [t](J.Ls)
C::: J.Ls(x) U Fs(J.Ls)(x)
J.Ls(x)
The third step follows from the induction hypothesis and the monotonicity of [t]
and the fourth step foliows because x ;:;:1 t is one of the constraints considered in
the definition of Fs. So each iteration of the while-loop preserves the invariant.
Part (ii). On termination of the loop, the worklist is empty. By contradiction we
establish that
Fs(Analysis) G Analysis
thereby showing the reductiveness of Fs on Analysis. For the proof by contradiction
suppose that Analysis[x]:;?) Fs(Analysis)(x) for some x E X and further suppose that
one reason is because the constraint x ;;::) t is not fulfilied. Consider the last time
that Analysis[y] was assigned to, for any variable y E FV(t).
If this was in step 1 then, since ali constraints are in W at the beginning of step 2,
for some i :::: 1 it is ensured that
Analysisi[x];;::) Analysisi_ 1 [x] U [t](Analysisi_ 1 )
where Analysisi_ 1 [y] contains the final value for y; hence [t] (Analysis 1 ) remains
stable for j :::: i - 1 showing that this case cannot apply.
372 6 Algorithms
It follows that Analysis[y] was last assigned in step 2. This must have been in the
context of dealing with a constraint y;;;] t'. But then, since (x ;;;] t) E infl[y], the
constraint x ;;;] t was added to the worklist and then we re-established, for some
later i ~ 1, that
Analysis;[x];;;] Analysis;_dx] U [t](Analysis;_ 1 )
As before, [t](Analysisj) remains stable for j ~ i - 1 showing that this case cannot
apply either. This completes the proof by contradiction.
Thus Fs is reductive on Analysis and by Tarski's Fixed Point Theorem (see Propo-
sition A.10):
p,s = lfp(Fs) [::; Analysis
Part (iii). That p,s = Analysis on termination of step 2 follows from the combination
of parts (i) and (ii). •
Assume that the size of the right hand sides of constraints is at most M ~ 1
and that the evaluation of a right hand side takes O(M) steps; further assume
that each assignment takes 0(1) step. Each constraint is influenced by at
most M flow variables and therefore the initialisation of the influence sets
takes O(N + N · M) steps. Writing Nx for the number of constraints in
infl[x] we note that LxEX Nx ::::; M · N. Assuming that L is of finite height
at most h ~ 1, the algorithm assigns to Analysis[x] at most h times, adding
Nx constraints to the worklist, for each flow variable x E X. Thus, the total
number of constraints added to the worklist is bounded from above by:
N + (h · L Nx) :S N + (h · M · N)
xEX
Since each element on the worklist causes a call to eval, the cost of the calls
is O(N · M + h · M 2 · N). This gives an overall complexity of O(h · M 2 · N).
6.1.2 Iterating in LIFO and FIFO

Extraction based on LIFO. The algorithm of Table 6.1 is an ab-
stract algorithm because it does not provide the details of the worklist nor
of the associated operations; a concrete algorithm is only obtained once this
information is supplied. We now show that the algorithm abstracts the algo-
rithms that we studied in Tables 2.8 and 3. 7 of Chapters 2 and 3, respectively.
In both of the earlier algorithms the worklist was implemented by a list that
was used as a stack, i.e. in a LIFO manner (meaning last-in first-out), as
specified by the operations in Table 6.2. However, the two algorithms differ
in the way constraints and influence sets are represented.
Example 6.5 A constraint of the form Analysis[C'] ~ fc(Analysis[i:']) is

represented on the worklist W of Table 2.8 by the pair (1:', C'); this is possible
empty =nil
function insert((x;;;) t),W)
return cons((x;;;) t),W)
function extract(W)
return (head(W), taii(W))
Table 6.2: Iterating in last-in first-out order (LIFO).
since each C uniquely identifies the transfer function fe. The influence sets
were indirectly represented through the flow, F; tobe more precise, infi[C'] =
{(C',C'') E F [ C" E Lab}.
The number N of constraints in a system generated from Intraprocedural
Data Flow Analysis is proportional to the number b of elementary blocks.
Furthermore, it is usual to take M = 1. Thus the upper bound on the
complexity of the abstract algorithm specialises to O(h · b); for an analysis
such as Reaching Definitions Analysis where h is proportional to b this gives
O(b 2 ). This agrees with the bound obtained in Example 2.30. •
Example 6.6 In Table 3.7 constraints of the form {t} ~ p, p 1 ~ por

{t} ~ P2 =? p 1 ~ p are represented on the worklist W by any one of the
flow variables Pl or P2 occurring on the left hand side. The influence sets are
represented using the edge array, E; tobe more precise, infl[p] = E[p] (viewed
as a set). The initialisation of the influence sets in step 1 of the algorithm
of Table 6.1 corresponds to step 2 of the algorithm in Table 3. 7; also the
inclusion on the worklist of ali the constraints in infl[p] is replaced by the
for-loop in step 3 of Table 3.7. Finally, note that Analysis[p] is written as
D[p].
The number N of constraints in a system generated from Control Flow Anal-
ysis is O(n 2 ) where n is the size of the expression (see the discussion about
the number of constraints in Section 3.4). Also, h is bounded by n and, once
again, M = 1. Thus the upper bound on the complexity of the abstract algo-
rithm specialises to O(n 3 ). This agrees with the bound obtained in Section
3.4. •
One disadvantage of the LIFO strategy as presented above, is that we do

not check for the presence of a constraint when adding it to the worklist.
Hence the worklist may evolve so as to contain multiple copies of the same
constraint and this may lead to unnecessarily recalculating terms before their
free variables have had much chance of getting new values. This is illustrated
in the following example; obviously a remedy is to modify the LIFO strategy
such that it never inserts a constraint when it is already present.
374 6 Algorithms
w X1 X2 X3 X4 xs X6
[xl, X2, X3, X4, Xs, X5] 0 0 0 0 0 0
[x2, X4, X2, X3, X4, Xs, X5] X? - - - - -
[x3, X5, X4, X2, X3, X4, Xs, X5] - x3? - - - -
[x2, X5, X4, X2, X3, X4, Xs, X5] - - x3? - - -

[x6, X4, X2, X3, X4, Xs, X5] - - - - - -
[x4, X2, X3, X4, Xs, X5] - - - - - X3?
[xs, X6, X2, X3, X4, X5, X5] - - - Xs? - -
[x4, X6, X2, X3, X4, Xs, X5] - - - - Xs? -
[x6, X2, X3, X4, Xs, X6] - - - - - -
[x2, x3, x4, xs, x5] - - - - - x3s?

[x3, X4, xs, x5] - - - - - -
[x4, xs, x6] - - - - - -
[xs,x6] - - - - - -
[x6] - - - - - -
[l - - - - - -
Figure 6.1: Example: LIFO iteration.
Example 6. 7 Continuing Examples 6.1 and 6.3, the LIFO worklist algo-
rithm obtained from Tables 6.1 and 6.2 operates as shown in Figure 6.1. The
first column is the worklist where we identify the equations by the variables
on the left hand side as in Example 6.3. The remaining columns are the
values of Analysis[xi]; "-" means that the value is unchanged and hence is
equal to that in the previous row. The first row of the table is the result
of the initialisation of step 1; each of the remaining rows corresponds to one
iteration through the loop of step 2. The improved strategy, where a con-
straint is never inserted when it is already present, is considered in Exercise
6.3. •
Extraction based on FIFO. An obvious alternative to the use of a

LIFO strategy is to use a FIFO strategy (meaning first-in first-out) where the
list is used as a queue. Again it may be worthwhile not to insert a constraint
into a worklist when it is already present. However, rather than going deeper
into the LIFO and FIFO strategies, we shall embark on a treatment of more
advanced insertion and extraction strategies.
6.2 lterating in Reverse Postorder

A careful organisation of the worklist may lead to algorithms that perform
better in practice than simply using the LIFO or FIFO strategies discussed
6.2 Iterating in Reverse Postorder 375
above; however, in general we will not be able to improve our estimation of

the worst case complexity to reflect this.
In this section we explore the idea that changes should be propagated through-
out the rest of the program before returning to re-evaluate a constraint. One
way of ensuring that every other constraint is evaluated before re-evaluating
the constraint which caused the change is to impose some total order on the
constraints. To obtain a suitable ordering we shall impose a graph structure
on the constraints (see below) and then use an iteration order based on re-
verse postorder (see Appendix C). This approach has been very successful
for Intraprocedural Data Flow Analysis and we shall show how the Round
Robin Algorithm can be obtained by fully implementing these ideas.
The graph structure of a constraint system. Given a con-

straint system S = (x; ;;;;) t;)~ 1 we can construct a graphical representation
G s of the dependencies between the constraints in the following way:
• there is a node for each constraint x; ;;;;) t;, and
• there is a directed edge from the node for X; ;;;;) t; to the node for Xj ;;;;) tj
if x; appears in tj (i.e. if Xj;;;) tj appears in infl[xi]).
This constructs a directed graph. Sometimes it has a root, i.e. a node from
which every other node is reachable through a directed path (see Appendix
C). This will generally be the case for constraint systems corresponding to
forward analyses of WHILE programs; in the case of Example 6.1 the root is
x1 . It will not in general be the case for constraint systems corresponding
to backward analyses for WHILE programs nor for constraint systems con-
structed for Constraint Based Analysis. We therefore need a generalisation of
the concept of root. One obvious remedy is to add a dummy root and enough
dummy edges from the dummy root to ordinary nodes that the dummy root
in fact becomes a root. A more elegant formulation, that avoids cluttering
the graph with dummy nodes and edges, is to consider a handle, i.e. a set of
nodes such that each node in the graph is reachable through a directed path
starting from one of the nodes in the handle (see Appendix C). Indeed, a
graph G has a root r if and only if G has {r} as a handle. In the case of Ex-
ample 6.2 a minimal handle is {x2, X4}. One can take the entire set of nodes
of a graph as a handle but it is more useful to choose a minimal handle: a
handle such that no proper subset is also a handle; as discussed in Appendix
C, minimal handles always exist (although they need not be unique).
We can then construct a depth-first spanning forest from the graph Gs and
handle Hs using the algorithm of Table C.l. This also produces an array,
rPostorder, that associates each node (i.e. each constraint x ;;;;) t) with its
number in a reverse postorder traversa! of the spanning forest. To lighten
the notation, particularly when presenting the Round Robin Algorithm later,
we sometimes demand that a constraint system (x; ;;;) t;)f:, 1 is listed in reverse
376 6 Algorithms
,--------1 XI f - - - - ,
(a)
Figure 6.2: (a) Graphical representation. (b) Depth-first spanning tree.
empty = (ni1,0)
function insert((x:;;;) t),(W.c,W.p))
return (W.c,(W.p U {x:;;;) t}))
function extract( (W.c,W.p))
if W.c = nil then
W.c := sort_rPostorder(W.p);
W.p := 0
return ( head(W.c), (taii(W.c),W.p))
Table 6.3: Iterating in reverse postorder.
postorder. The advantages of reverse postorder over other orderings, such as

preorder and breadth-first order, are discussed in Appendix C.
Example 6.8 Figure 6.2( a) shows the graphical representation of the con-
straints of Example 6.1; again we use the left hand side of the equation as
the name of the equation. The node for XI is the root of the graph. Figure
6.2(b) shows a depth-first spanning tree for the graph; the associated reverse
postorder is XI, · · · , X6. •
Extraction based on reverse postorder. Conceptually, we now
modify step 2 of the worklist algorithm of Table 6.1 so that the iteration
amounts to an outer iteration that contains an inner iteration that visits the
nodes in reverse postorder.
To achieve this, without actually changing Table 6.1, we shall organise the
worklist W as a pair (W.c,W.p) of two structures. The first component, W.c,
is a list of current nodes to be visited in the current inner iteration. The
W.c W.p Xl X2 X3 X4 X5 X6
[J {xl, ... ,x6} 0 0 0 0 0 0
[x2, X3, X4, X5, X6] {x2, x4} X? - - - - -
[x3, X4, X5, X6] {x2,X3,X4,X6} - X37 - - - -
[x4, x5, x6] {x2,x3,x4,x6} - - x3? - - -
[x5,x6] {x2, ... 'x6} - - - x5? - -
[xB] {x2,· ··,x6} - - - - x5? -

[x2, X3, X4, X5, X6] 0 - - - - - x35?
[x3, X4, X5, X6] 0 - - - - - -
[x4,x5,x6] 0 - - - - - -
[x5,x6] 0 - - - - - -
[xB] 0 - - - - - -
[J 0 - - - - - -
Figure 6.3: Example: Reverse postorder iteration.
second component, W.p, is a set of pending nodes to be visited in a later

inner iteration. Nodes are always inserted into W.p and always extracted
from W.c; when W.c is exhausted the current inner iteration has finished
and in preparation for the next we must sort W.p in the reverse postorder
given by rPostorder and assign the result to W.c. The details are provided by
the operations of Table 6.3; here (taii(W.c),W.p) denotes the pair whose first
component is the tail of the list W.c and whose second component is W.p.
Clearly one could dispense with sorting the set W.p if it was implemented by
a suitable data structure that allows the insertion and extraction of elements
in their appropriate order. This is facilitated by a priority queue where
each element has a priority associated with it; in our case the priority is
the rPostorder number. One of the better ways of implementing a priority
queue is as a 2-3 tree and in this representation an element can be inserted
or extracted in O(log2 N) steps where the priority queue contains at most N
elements.
However, the amortised complexity of our scheme is equally good. To see
this note that clearly a list of N elements can be sorted in O(N ·log2 (N))
steps. Further suppose that we use a linked list representation of lists; then
inserting an element to the front of a list, as well as extracting the head of a
list, can be done in constant time. Thus the overall complexity for processing
N insertions and N extractions is O(N ·log2 (N)) in both schemes.
Actually we can do somewhat better under the special circumstances of our
algorithm. Recall that there are at most N constraints that are ali known
from the outset. Let us represent W.p as a bit vector of length N and agree
that it takes constant time to access or modify a component. Then insertion
into W.p is performed by setting a bit to 1 and sorting of W.p is performed
378 6 Algorithms
by a for-loop running through all N constraints, and recording a constraint

in the sorted list if and only if the bit is 1. Then we can guarantee that at
most N insertions and N extractions can be done in O(N) steps; hence the
complexity estimation of Section 6.1.1 stiH holds.
Also the overall correctness of the algorithm carries over from Lemma 6.4
because we stiH have an abstract worklist; simply take W = W.c U W.p.
Example 6.9 Returning to Examples 6.1 and 6.3, we shall consider the
reverse postorder XI,···, X6 of Example 6.8. Using the algorithm of Table
6.3, we get the iterations shown in Figure 6.3. Note that we perform fewer
iterations than when using the LIFO strategy (see Example 6.7). Improved
versions of Table 6.3 are considered in Exercises 6.6 and 6.7. •
6.2.1 The Round Robin Algorithm

Now suppose that we change the above algorithm such that each time W.c is
exhausted we assign it the list [1, · · ·, N] rather than the potentially shorter
list obtained by sorting W.p. Clearly this may lead to more evaluations of
right hand sides of constraints but it simplifies some of the book-keeping
details. Indeed, now our only interest in W.p is whether or not it is empty;
let us introduce a boolean, change, that is false whenever W.p is empty. Also
let us split the iterations into an overall outer iteration having an explicit
inner iteration; each inner iteration will then be a simple iteration through
all constraints in reverse postorder.
We thus arrive at the Round Rabin Algorithm shown in Table 6.4. The
algorithm starts by initialising Analysis and change (step 1). The outer itera-
tion (step 2) is a while-loop that begins by modifying change (corresponding
to what would have happened in extract); it then has an inner iteration (a
for-loop) that updates Analysis by recomputing the right hand sides of con-
straints. The algorithm continues iterating as long as any part of the solution
changes (indicated by change being set to true).
Example 6.10 Using the reverse postorder XI,··· ,x6 of Example 6.8 to
solve the equations of Example 6.1, the Round Robin Algorithm of Table 6.4
operates as shown in Figure 6.4. The lines marked * record the assignment
of false to change at the beginning of the body of the while-loop. •
Theoretical properties. We first study the correctness of the Round

Robin Algorithm and then establish a striking bound on its complexity in the
special case of Bit Vector Frameworks (as studied in Exercise 2.9 of Chapter
2).
Lemma 6.11 Given the assumptions, the algorithm of Table 6.4 com-
putes the least solution of the given constraint system, S. •
INPUT: A system S of constraints: XI ;;;;) ti, · · · , x N ;;;;) tN

ordered 1 to N in reverse postorder
OUTPUT: The least solution: Analysis

for ali x E X do
Analysis[x] := .l
change := true;
Step 2: Iteration (updating Analysis)

while change do
change := false;
for i := 1 to N do
new := eval(ti.Analysis);
if Analysis[xi] ~ new then
change := true;
Analysis[xi] := Analysis[xi] U new;
USING: function eval(t.Analysis)

return [t](Analysis)
Table 6.4: The Round Robin Algorithm.
change XI X2 X3 X4 X5 X6
true 0 0 0 0 0 0
* false
true X? - - - - -
true - x3? - - - -
true - - X3? - - -
true - - - X57 - -
true - - - - x5? -
true - - - - - x35?
* false
false - - - - - -
false - - - - - -
false - - - - - -
false - - - - - -
false - - - - - -
false - - - - - -
Figure 6.4: Example: Round Robin iteration.

380 6 Algorithms
Proof Since the algorithm of Table 6.4 is obtained in a systematic manner from
that of Table 6.1, the correctness proof can be obtained in a systematic manner
from that of Lemma 6.4; we leave the details to Exercise 6.9. •
We shall say that the constraint system (xi ;;;J ti)k 1 is an instance of a Bit
Vector Framework when L = P(D) for some finite set D and when each right
hand side ti is ofthe form (x]inY? )uY? for sets Y;k ~ D and variable Xj, E X.
Clearly the classical Data Flow Analyses of Section 2.1 produce constraint
systems of this form (possibly after expansion of a composite constraint Xi ;;;J
t7i
t} U · · · U t7i ).
into the individual constraints Xi ;;;J t}, · · ·, Xi ;;;J
Consider a depth-first spanning forest T and a reverse postorder rPostorder
constructed for the graph Gs with handle Hs. We know from Appendix C
that the loop connectedness parameter d( G s, T) 2 Ois defined as the largest
number of so-called back edges found on any cycle-free path of Gs. We also
know that the back edges are exactly those edges that are not topologically
sorted by rPostorder, i.e. for which the target of the edge does not have an
rPostorder number that is strictly larger than that of the source.
Let us say that the algorithm of Table 6.4 has iterated n 2 1 times if the
loop of step 1 has been executed once and the while-loop of step 2 has been
executed n- 1 times. We then have the following result:
Lemma 6.12 Under the assumptions stated above, the algorithm of Table
6.4 halts after at most d(Gs, T) + 3 iterations. It therefore performs at most
O((d(Gs, T) + 1) · N) assignments. •
Proof If a path contains d back edges, the while-loop of step 2 takes at most d + 1
iterations to propagate a change throughout the path. To be specific, it takes one
iteration for the value to arrive at the source of the first back edge; this follows
since up to this point the nodes in the path are numbered in increasing sequence.
After that, it takes one iteration of the while-loop for the value to reach the source
of the next back edge, and so on. So the algorithm needs at most d + 1 iterations
to propagate the information.
One more iteration of the while-loop suffices for detecting that there are no further
changes. We also have to count one for the iteration of the for-loop in step 1. This
gives an upper bound of d + 3 .:; d( G s, T) + 3 on the number of iterations.
Clearly each iteration can perform at most O(N) assignments or evaluations of right
hand sides. This gives an upper bound of O((d(Gs, T) + 1) · N) on the number of
assignments. •
For WHILE programs we know from Appendix C that the loop connectedness
parameter is independent of the choice of depth first spanning forest, and
hence of the choice of the reverse postorder recorded in rPostorder, and that
it equals the maximal nesting depth d of while-loops. It follows that Lemma
6.12 gives an overall complexity of O( (d + 1) · b) where b is the number of
elementary blocks. We would normally expect this bound to be significantly
smaller than the O(b 2 ) obtained in Examples 2.8 and 6.5.
It is worth mentioning that an empirica! study of Fortran programs once

reported that the loop connectedness parameter seldom exceeds 3; this gave
rise to the Folk Theorem that the Round Robin Algorithm usually has linear
time complexity.
Example 6.13 The WHILE program of Example 6.1 has a loop connect-
edness parameter of 1. According to Lemma 6.12 the Round Robin Algorithm
will perform at most 4 iterations (1 for step 1 and 3 for step 2 of Table 6.4).
However, Example 6.10 managed to succeed in only 3 iterations (1 for step
1 and 2 for step 2). •
6.3 Iterating Through Strong Components

As was said above, a careful organisation of the worklist is a key factor in
obtaining algorithms having a good practica! performance. Iterating through
the entire system of constraints in reverse postorder (as in Section 6.2) is a
first step in this direction. A further step that often pays off in practice
is to identify the so-called strong components in the system of constraints
and to process them one by one; the processing of each strong component
means iterating through the constraints of that strong component in reverse
postorder (in the manner of Section 6.2).
Strong Components. Once again, we exploit the graph structure on

constraints introduced in Section 6.2. Recall that a graph is strongly con-
nected if every node is reachable from every other node (see Appendix C).
The strong components of a graph are its maximal strongly connected sub-
graphs. The strong components partition the nodes in the graph (Fact C.3).
The interconnections between components can be represented by a reduced
graph: each strong component is represented by a node in the reduced graph
and there is an edge from one strong component to another if there is an edge
in the original graph from some node in the first strong component to a node
in the second strong component and provided that the two strong compo-
nents are not the same. The reduced graph is always a DAG, i.e. a directed,
acyclic graph (Lemma C.5). As a consequence, the strong components can
be linearly ordered in topologica[ order: scl :::; sc2 (where scl and sc2
are nodes in the reduced graph) whenever there is an edge from SC 1 to SC 2 ;
such a topologica! order can be obtained by constructing a reverse postorder
for the reduced graph (as follows from Corollary C.ll).
Example 6.14 Consider once again the equation system of Example 6.1.
Its strong components and the reduced graph are shown in Figure 6.5. There
are two possible topologica! orderings of the strong components. One is
{x1}, {x2,x3}, {X4,X5}, {x5} and the other is {xl}, {x4,x5}, {x2,x3}, {x5}.
382 6 Algorithms
§]
(a) (b)
Figure 6.5: (a) Strong components. (b) Reduced graph.
INPUT: A graph partitioned into strong components
OUTPUT: srPostorder
METHOD: sec:= 1;
for each sec in topologica! order do
rp := 1;
for each x ;;;! t in the strong component sec
in local reverse postorder do
srPostorder[x ;;;! t] := (scc,rp );
rp := rp + 1
sec := sec + 1;
Table 6.5: Pseudocode for constraint numbering.
In this example each strong component was an outermost loop. This holds
in general for both forward and backward flow graphs for programs in the
WHILE language. •
For each constraint we need to record both the strong component it oc-
curs in and its number in the local reverse postorder for that strong com-
ponent. We shall do so by means of a numbering srPostorder that to each
constraint x ;;;! t assigns a pair (sec, rp) consisting of the number sec of the
strong component and the number rp of its reverse postorder numbering in-
side that strong component. When srPostorder[x ;;;! t] = (sec, rp) we shall
write fst(srPostorder[x ;;;! t]) for sec, and snd(srPostorder[x ;;;! t]) for rp. One
way to obtain srPostorder is using the algorithm of Table 6.5.
The Algorithm. The basic method of the new algorithm is that strong
components are visited in topologica! order with nodes being visited in reverse
postorder within each strong component.
Conceptually, we now modify step 2 of the worklist algorithm of Table 6.1
so that the iteration amounts to three levels of iteration; the outermost level
deals with the strong components one by one; the intermediate level performs
a number of passes over the constraints in the current strong component; and
the inner level performs one pass in reverse postorder over the appropriate
constraints.
To achieve this, without actually changing Table 6.1, we shall again organise
the worklist W as a pair (W.c,W.p) of two structures. The first component,
W.c, is a list of current nodes to be visited in the current inner iteration.
The second component, W.p, is a set of pending nodes to be visited in a
later intermediate or outer iteration. Nodes are always inserted into W.p
and always extracted from W.c; when W.c is exhausted the current inner
iteration has finished and in preparation for the next we must extract a
strong component from W.p, sort it and assign the result to W.c. The details
are provided by the operations of Table 6.6.
Intuitively, an inner iteration ends when W.c is exhausted, an intermediate
iteration ends when sec gets a higher value than last time it was computed,
and the outer iteration ends when both W.c and W.p are exhausted.
Again the lists can be organised as priority queues. This time the priority of
x ;:;) t is the srPostorder information about the strong component, sec, and the
local reverse postorder number, rp; rather than directly using pairs, (sec, rp),
it may be helpful to use a linearised representation with numbers such that
the lexicographic ordering on the pairs corresponds to the arithmetic ordering
on the numbers.
Example 6.15 Consider the ordering {x!}, {x2,x3}, {x4,x5}, {x6} of the
strong components of Example 6.14. The algorithm iterating through strong
components (Table 6.6) produces the walkthrough of Figure 6.6 when solving
the system. Note that even on this small example the algorithm performs
slightly better than the others (ignoring the cost of maintaining the worklist).
Improved versions of Table 6.6 are considered in Exercises 6.11 and 6.12. •
It is also possible to split the set W.p of pending constraints into two col-
lections: W.pc for those that relate to the current strong component and
W.pf for those that relate to future strong components. (Since the reduced
graph is a DAG there cannot be any constraints relating to earlier strong
components.) We leave these details to Exercise 6.12.
Once more the overall correctness of the algorithm carries over from Lemma
6.4; also the estimation of the complexity carries over from Section 6.1.1.
384 6 Algorithms
empty = (ni1,0)
function insert({x:;;;) t),{W.c,W.p))
return (W.c,(W.p U { x :;;;) t}))
function extract{{W.c,W.p))
local variables: sec, W_scc
if W.c = nil then
sec := min{fst(srPostorder[x:;;;) t]) 1 (x :;;;) t) E W.p };
W_scc := {(x:;;;) t) E W.p 1 fst(srPostorder[x:;;;) t]) =sec};
W.c := sort_srPostorder(W_scc);
W.p := W.p \ W_scc;
return ( head{W.c), (taii{W.c),W.p))
Table 6.6: Iterating through strong components.
W.c W.p X1 X2 X3 X4 xs X6
[l {x1, ... ,x6} 0 0 0 0 0 0
[l {x2,· .. ,x6} X? - - - - -
[x3] {x3,· ··,x6} - X37 - - - -
[l {x2, · · · ,x6} - - X37 - - -
[x3] {x4,xs,x6} - - - - - -
[l {x4,xs,x6} - - - - - -
[xs] {xs,x6} - - - Xs? - -
[l {X4,X5,X6} - - - - Xs? -
[x5] {x6} - - - - - -
[l {x6} - - - - - -
[l 0 - - - - - x3s?
Figure 6.6: Example: Strong component iteration.
Concluding Remarks
Iterative solvers. Worklist algorithms have a long history; an early
presentation of a general worklist algorithm for Data Flow Analysis may be
found in [96]. A number of special purpose iterative algorithms are pre-
sented in [69]; this covers versions for forward Data Flow Analysis problems
(based on reverse postorder traversa! of the depth-first spanning forest) and
backward Data Flow Analysis problems (based on postorder traversa! of the
depth-first spanning forest); it also covers versions in so-called "integrated
form" (roughly meaning that constraints are placed on the worklist) and
"segregated form" (roughly meaning that flow variables are placed on the
worklist); it also deals with the Round Robin Algorithm. A theoretical study
of Round Robin Algorithms may be found in [92]. The empirica! study of
the loop connectedness parameter for Fortran programs, giving rise to the
Folk Theorem that the Round Robin Algorithm operates in linear time in
practice, is contained in [98].
The use of strong components to speed up iterative algorithms has been
considered by a number of authors (e.g. [77, 87]). The treatment in Section
6.3 and Exercise 6.12 is based on [77] where the worklists W.c, W.pc, and
W.pf are represented by priority queues currentQ, pendingQ, and futureQ,
respectively. We refer to [77] for examples for which iteration over strong
components performs better than either the basic worklist algorithm or the
Round Robin Algorithm. There are many ways to implement priority queues
as balanced search trees; the use of 2-3 trees is explained in [4].
Local solvers. Suppose that the set of constraints is very large but that
we are only interested in the values of a small subset of the flow variables.
In this situation the classical worklist solvers may compute information in
which we have no interest; hence it may be better to perform a local fixed
point computation where one finds a partial solution for the flow variables of
interest (and of course all flow variables which directly or indirectly influence
them). For best performance the local fixed point solvers perform a dynamic
determination of what is essentially the strong components of the constraints
of interest.
One such algorithm is the top down solver [29]; this is a general fixed point
algorithm that was originally developed for program analysis tools for logic
programming languages. The algorithm proceeds top down; as it meets a
new flow variable, it attempts to produce a solution for that flow variable.
Its practica! performance is very good and is competitive with the more
sophisticated versions of the worklist algorithm.
Another algorithm is the worklist based local fixed point solver [51, 54] that
uses time stamps to impose an ordering on the elements of the worklist. The
worklist is now a maximum priority queue - the priority of an entry being
given by its time stamp. Elements are selected from the worklist in an order
which gives a run-time approximation to strong components (as with the top
down solver).
A further refinement is the differential worklist based local fixed point solver
[52, 53]. The differential worklist algorithm aims to minimise the amount
of recomputation that occurs when a value changes; it does this by only
recomputing the actual sub-terms influenced by the changed value and by
only computing the incremental change due to the difference between the old
and new values. This algorithm compares well in practice with a number of
special purpose algorithms reported in the literature. (See Exercise 6.5 for a
key insight.)
386 6 Algorithms
Efficient algorithms for restricted forms of systems. Elim-

ination methods have been proposed as an alternative to the iterative ap-
proaches for solving systems. Most of this development has concentrated on
the kind of systems generated for Data Flow Analysis. Ryder and Paull [146]
provide a survey of different elimination methods.
A very successful elimination method is structural analysis [154]. The first
phase of structural analysis performs a postorder search of the graph rep-
resenting the constraint system in order to identify control structures; here
postorder is with respect to a depth-first spanning forest for the graph and as
a consequence, deeper nested control structures are identified earlier. Having
identified a control structure, its nodes are reduced to a single node to pro-
duce a new, derived graph. This process terminates when there is only one
node. The result of the first phase is a control tree which records the reduc-
tion sequence; this can be viewed as a technique for translating machine code
into high-level programs (where the primitives are those control structures
considered in structural analysis). The second phase of structural analysis
then traverses the control tree in order to solve the constraint system; this
takes the form of a bottom-up traversa! followed by a top-down traversa!.
The bottom-up traversa! associates a transfer function with each node in the
control tree; the transfer function describes the effect of analysing that part
of the program. The top-down traversa! evaluates the transfer functions upon
appropriate arguments. The second phase of structural analysis essentially
amounts to high-level Data Flow Analysis [144] which again has some of the
flavour of Section 1.6.
An early elimination algorithm for Data Flow Analysis was based on interval
analysis [11]. An interval can briefly be described as a single entry cycle
together with an acyclic extension. The algorithm performs in a similar way
to structural analysis. The first phase constructs a derived sequence of graphs
that is usually coarser than the control tree produced by structural analysis.
The second phase consists of a backward traversa! of the derived sequence
followed by a forward traversa!.
We conclude by mentioning another elimination method based on path al-
gebras [170, 171]. For intraprocedural analyses, path expressions amount to
regular expressions, and some very fast algorithms exist for solving analyses
over such structures.
Practica! systems. A number of generic tools for implementing pro-

gram analyses have been constructed. The analyses are specified using a
specification language; in some systems this is a special purpose language
(e.g. a functional language) whereas in others it is the implementation lan-
guage of the tool (e.g. C++). The tools then provide one or more algorithms
for solving equations or constraints; the details of these algorithms depend
on the scope of the tools; often the tools are restricted to certain classes of
languages (e.g. they might not support languages with dynamic dispatch) or
Mini Projects 387
cert ain classes of analyses (e.g. they may not support interprocedural anal-
yses). lnternally, some of the systems work on abstract syntax trees, others
work on flow graphs and yet others work directly on the equations or con-
straints.
The specification languages of tools like Spare [177], System Z [185] and PA G
[104] are based on eager functional languages and they support high-level
definitions of complete lattices and the associated analysis functions; Spare
and System Z are inspired by a denotational approach to program analysis
(see e.g. [117]) whereas PAG is closer to the traditional Data Flow Analysis
approach. The above tools build on the ideas of Abstract Interpretation
by allowing the user to control the complexity of the analyses by specifying
operations related to widening operators (see Section 4.2 and Exercise 6.13).
Other program analysis tools are based on other specification mechanisms
like graph rewriting [17] or modal logic [97].
To improve the efficiency of the generated analysers, some of the tools can
take advantage of special properties of the analyses. An example is PAG
[104] which supports several implementations of sets including bit vectors,
AVL trees (see [4]) and BDD's [26] (binary decision diagrams). Another ex-
ample is Sharlit [172] which provides an equation solver based on elimination
techniques for Bit Vector Frameworks.
BANE [8] is a general constraint solver for a very general class of set con-
straints [7] (see the Concluding Remarks to Chapter 3). The constraints
are sufficiently general that the system has been used successfully for imple-
menting both Constraint Based Analyses and Type Systems. It is written in
Standard ML but also admits a simple textual interface in which a system of
constraints can be specified.
Mini Projects
Mini Project 6.1 Comparison of Algorithms
Recall that a Bit Vector Framework (see Section 6.2 and Exercise 2.9) is a
special case of a Monotone Framework with
• L = (P(D), ~) where D is a finite set and ~ is either <;;; or 2, and
• :F = {f : P(D) -+ P(D) 1 3Y}, Yj <;;; D : \iY <;;; D :

f(Y) = (Y n Y}) u Yj}
lmplement a system that will accept a description of a Bit Vector Framework

and a description of a constraint system that is an instance of a Bit Vector
Framework and that will produce the least solution. It should be possible to
388 6 Algorithms
direct the system to use (i) the Round Rabin Algorithm (see Table 6.4), or
the worklist algorithm of Table 6.1 based on (ii) last-in first-out (see Table
6.2 and Exercise 6.3), (iii) reverse postorder (see Table 6.3 and Exercise 6.6)
and (iv) strong components with local reverse postorders (see Table 6.6 and
Exercise 6.11).
Design suitable experiments to allow an empirica! comparison of the worst-
case and average-case performance of the four algorithms.
For the more ambitious: Generalise your system to accept descriptions of
Monotone Frameworks and more general instances of constraint systems.
Apply the system to the equations and constraints generated in Chapters
2 and 3. •
Mini Project 6.2 Algorithms for Conditiona! Constraints
Consider the following simplified form of set constraints (as discussed in the
Concluding Remarks to Chapter 3) where the terms on the right hand sides
of the constraints are given by:
t x 1 _i 1 c 1 t1 u t2 1 t1 n t2 1
if ii -=1- _l then t2 1 if c [::; t1 then t2
Here x stands for a flow variable, c for a primitive constant (like {fn x => x 1 }
of Example 6.2), and if · · · then · · · denotes a conditiona! constraint as con-
sidered in Example 6.2.
1. Verify that the assumptions of this chapter stiU hold; in particular, that
the evaluation of terms is stiU monotone.
2. Observe that once a condition becomes true, it remains so. Modify the
LIFO worklist algorithm (see Tables 6.1 and 6.2) such that it simplifies
constraints as conditions become true.
3. State and prove a correctness result for the new algorithm. What can
you say about its complexity?
4. Modify the new algorithm to implement the optimisation suggested by
Exercise 6.3.
5. Investigate the application of these ideas to the material of Chapter 3.
For the more ambitious: Explore the extent to which similar optimisations
are possible for the other worklist algorithms of this chapter. Give particular
attention to the maintenance of the ordering on the constraints; what are the
implications for the complexity of the modified algorithms? •
Exercises 389
Exercises
Exercise 6.1 In Example 6.7 the result of step 1 produced the worklist
W = [x 1 ,• ·,x6 ]. Redo the example assuming that step 1 instead produced
the worklist W = [x6, · ·,x1]. Compare the number of iterations. •
Exercise 6.2 Consider the program ((fn x => x) (fn y => y)) from
Example 6.2. Give a walkthrough of the worklist algorithm of Table 6.1 to
solve these constraints using the LIFO extraction strategy of Table 6.2. •
Exercise 6.3 Modify the LIFO extraction strategy of Table 6.2 so that a
constraint is never inserted into the worklist W when it is already present.
Then redo Example 6. 7 using the modified strategy and compare the number
of iterations. •
Exercise 6.4 In Appendix C we explained that the set Dom(n) of domi-

nators of a node n in a graph (N, A) with handle H can be described as the
greatest solution of the following equation system:
ifn E H
Dom(n)- { {n}
- {n} u n(n',n)EA Dom(n') otherwise
(This can be regarded as an intersection based analysis in the sense of Section

2.1.) Developa worklist algorithm for computing dominator sets. •
Exercise 6.5 Consider a constraint system

( X•... ::J
- ~
t 1 U · · · U tM)~l
t '1..-
where each t{ has size 0(1) and can be evaluated in 0(1) steps. Show that
the worklist algorithm can solve this system in O(h · M 2 • N) steps. Next
show that the constraint system is equivalent to the constraint system
in the sense that they have the same solutions. Finally show that the worklist
algorithm can solve this system in O(h · M · N) steps. •
Exercise 6.6 Modify the reverse postorder extraction strategy of Table

6.3 so that a constraint is never inserted into W.p when it is already present
in either W.p or W.c. Then redo Example 6.9 using the modified strategy
and compare the number of iterations. •
390 6 Algorithms
Exercise 6. 7 In Section 6.2 we discussed using two priority queues for

the worklist algorithm based on reverse postorder: W.c for the constraints
to be considered in the current "inner" iteration and W. p for those to be
considered in the next "inner" iteration.
Develop a concrete algorithm based on these ideas so that as few operations
as possible need to be performed. Explore the idea of adding a constraint
x' :;;;) t' to W.c or W.p depending on how rPostorder[x' :;;;) t'] compares to
rPostorder[x :;;;) t] where x :;;;) t is the constraint just considered in step 2 of
Table 6.1. The objective should be to keep W.c as large as possible without
destroying the iteration order. Then redo Example 6.9 and compare the
number of iterations with the result from Exercise 6.6. •
Exercise 6.8 Consider the equations used to introduce Available Expres-

sions Analysis in Example 2.5 of Chapter 2; when expressed as a constraint
system in the flow variables {x1 , · · · , x10 } it takes the form
X1 0 X6 x1 U {a+b}
X2 X6 X7 x2 U {a*b}
X3 x1 n xw xs X3 U {a+b}
X4 Xs Xg x4\{a+b,a*b,a+1}
X5 Xg xw x5 U {a+b}
where x1, · · ·, X5 correspond to AEentry(l), · · ·, AEentry(5) and x6, · · ·, xw cor-

respond to AEexit(l), · · ·, AEexit(5).
Draw the graph ofthis system as described in Section 6.2. Use the depth-first
search algorithm of Appendix C to assign a reverse postorder numbering to
the nodes in the graph. Give a walkthrough of the Round Rabin Algorithm
to produce a solution to the system. •
Exercise 6.9 Complete the details of the proof of Lemma 6.11 concerning
the correctness of the Round Robin Algorithm. •
Exercise 6.10 Draw the graph of the constraint system in Exercise 6.8.
Identify the strong components of the graph (see Appendix C) and write
down a srPostorder numbering for the nodes in the graph. Use the algorithm
of Section 6.3 to salve the system. •
Exercise 6.11 Modify the strong component extraction strategy of Table

6.6 so that a constraint is never inserted into W.p when it is already present
in either W.p or W.c. Then redo Example 6.15 using the modified strategy
and compare the number of iterations. •
Exercises 391
Exercise 6.12 In Section 6.3 we discussed using two priority queues for
the worklist algorithm based on strong components: W.c for the constraints to
be considered in the current "inner" iteration, W.pc for those tobe considered
in the next "inner" iteration, and W.pf for those to be considered in future
"outer" iterations.
Develop a concrete algorithm based on these ideas so that as few operations
as possible need to be performed. Explore the idea of adding a constraint
x';;;) t' to W.c, W.pc or W.pf depending on how srPostorder[x';;;) t'] compares
to srPostorder[x ;;;) t] where x ;;;) t is the constraint just considere_d in step
2 of Table 6.1. The objective should be to keep W.c and W.pc as large as
possible without destroying the iteration order. Then reda Example 6.15 and
compare the number of iterations with the result from Exercise 6.11. •
Exercise 6.13 Modify the worklist algorithm of Table 6.1 to use a widen-
ing operator (see Section 4.2) over L. Does the widening operator over L give
rise to a widening operator over X ---t L? Prove that the resulting worklist
algorithm computes an upper approximation to the least solution of the con-
straint system. Also prove that it always terminates when L is a complete
lattice (even when it does not satisfy the Ascending Chain Condition). •
Exercise 6.14 A monotone function f is fast whenever f of ~ fU id and

a Monotone Framework (L, F) is fast whenever ali functions in F are fast.
Notice that if a monotone function is idempotent then it is also fast; use this
to show that ali Bit Vector Frameworks (see Exercise 2.9) are fast.
It is frequently possible to approximate a function by a fast function. Let f
bea monotone function and define the foliowing sequence (for n;::: 0):
/(n) = (f U idt
Assuming that there exists a number iJ such that J(it) = f(i,+l) we define
the fastness closure of f to be:
1 = /(iJ)
Show that f(i,) = f(j) for j;::: iJ and conclude that the the fastness closure
is weli-defined. Next prove that 1 is idempotent and hence fast. Finaliy
show that 1 ;;;) f U id and that they are equal when f is fast and distributive
(i.e. additive).
Suppose that f is distributive (and hence monotone) and consider the func-
tional F defined by
F(g) = id u g of
as might arise for a simple while-loop where the body is described by f. Prove
that n
pn+l(l_) =(fU idt = U /j
j=O
392 6 Algorithms
holds for n ~ O. Conclude that if fis the fastness closure of f then Jfp(F) = f.
This shows that for fast Distributive Frameworks (including all Bit Vector
Frameworks) there is a simple non-iterative way of solving data fiow equations
for programs with a simple loop structure. •
Appendix A
Partially Ordered Sets
Partially ordered sets and complete lattices play a crucial role in program
analysis and in this appendix we shall summarise some of their properties.
We review the basic approaches for how to construct complete lattices from
other complete lattices and state the central properties of partially ordered
sets satisfying the Ascending Chain and Descending Chain Conditions. We
then review the classical results about least and greatest fixed points.
A.l Basic Definitions

Partially ordered set. A partial ordering is a relation ~: L x L ---+
{ true,fa.lse} that is reflexive (i.e. Vl : l ~ l), transitive (i.e. Vh, l2, b : h ~
l2 A l2 ~ l3 ==> h ~ la), and anti-symmetric (i.e. Vh, h : h ~ l2 Ah ~ h ==>
h = l2). A partially ordered set (L, ~) is a set L equipped with a partial
ordering ~ (sometimes written ~L). We shall write h ;;;;) h for h ~ l2 and
h C l2 for h ~ h A h =1- l2.
A subset Y of L has l E L as an upper bound if Vl' E Y : l' ~ l and as
a lower bound if Vl' E Y : l' ;;;;) l. A least upper bound l of Y is an upper
bound of Y that satisfies l ~ lo whenever lo is another upper bound of Y;
similarly, a greatest lower bound l of Y is a lower bound of Y that satisfies
lo ~ l whenever lo is another lower bound of Y. Note that subsets Y of a
partially ordered set L need not have least upper bounds nor greatest lower
bounds but when they exist they are unique (since ~ is anti-symmetric) and
n
they are denoted UY and Y, respectively. Sometimes U is called the join
n
operator and the meet operator and we shan write h u t2 for U{h, t2} and
similarly h n b for n{h, b}.
Complete lattice. A complete lattice L = (L, ~) = (L, ~. U, _1_, T) n,

is a partially ordered set (L, ~) such that all subsets have least upper bounds
394 A Partially Ordered Sets
{2,3} {3}
{3} {2,3}
(a)
Figure A.l: Two complete lattices.
as well as greatest lower bounds. Furthermore, _l = U0 = nL is the least

n
element and T = 0 = UL is the greatest element.
Example A.l If L = (P(S), ~)for some set S then ~ is ~ and UY =

UY, nY = nY, j_ = 0 and T = s. If L = (P(S), 2) then ~ is 2 and
UY = nY, nY = UY, j_ = s and T = 0.
Hence (P(S), ~) as well as (P(S), 2) are complete lattices. In the case where
S = {1, 2, 3} the two complete lattices are shown on Figure A.l; these draw-
ings are often called Hasse diagrams. Here a line "going upwards" from some
h to some l2 means that h ~ l2; we do not draw lines that follow from
reflexivity or transitivity of the partial ordering. •
Lemma A.2 For a partially ordered set L = (L, ~) the claims
(i) L is a complete lattice,
(ii) every subset of L has a least upper bound, and
(iii) every subset of L has a greatest lower bound
are equivalent. •
Proof Clearly (i) implies (ii) and (iii). To show that (ii) implies (i) let Y ~ L and
define
(A.l)
and let us prove that this indeed defines a greatest lower bound. All the elements
of the set on the right hand side of (A.l) are lower bounds of Y so clearly (A.l)
defines a lower bound of Y. Since any lower bound of Y will be in the set it follows
that (A.l) defines the greatest lower bound of Y. Thus (i) holds.
A.l Basic Definitions 395
To show that (iii) implies (i) we define UY = n{l E L 1 Vl' E y : l' ~ l}.
Arguments analogous to those above show that this defines a least upper bound
and that (i) holds. •
Moore family. A Moore family is a subset Y of a complete lattice

L = (L, ~)that is closed under greatest lower bounds: VY' ~ Y: nY' E Y.
It follows that a Moore family always contains a least element, nY, and
a greatest element, n0, which equals the greatest element, T, from L; in
particular, a Moore family is never empty.
Example A.3 Consider the complete lattice (P(S), ~)of Figure A.l (a).
The subsets
{{2}, {1, 2}, {2, 3}, {1, 2, 3}} and {0, {1, 2, 3}}
are both Moore families, whereas neither of
{{1 }, {2}} and {0, {1 }, {2}, {1, 2}}
are. •
Properties of functions. A function f : L1 ~ L 2 between partially
ordered sets L1 = (L1, ~1) and L2 = (L2, ~2) is surjective (or onto or epic)
if
and it is injective (or 1-1 or manie) if
Vl,l' E L1: f(l) = f(l')::::} l = l'

The function f is monotone (or isotone or order-preserving) if
\Il, l' E L1 : l ~1 l' ::::} f(l) ~2 f(l')
It is an additive function (or a join morphism, sometimes called a distributive

function) if
and it is called a multiplicative function (ora meet morphism) if
The function f is a completely additive function (or a complete join mor-

phism) if for all Y ~ L1:
and it is completely multiplicative (or a complete meet morphism) if for all

Y ~ L1:
f(nlY) = n2{f(l') Il' E Y} whenever nly exists

Clearly U1 Y and n1Y always exist when L1 is a complete lattice; when L2
is not a complete lattice the above statements also require the appropriate
least upper bounds and greatest lower bounds to exist in L 2 . The function
f is affine if for all non-empty Y ~ L1
J(U lY) = u2{f(l') Il' E Y} whenever uly exists (and y-=!= 0)
and it is strict if f(l_l) = 1_ 2 ; note that a function is completely additive if
and only if it is both affine and strict.
Lemma A.4 If L = (L, !;::;, u, n, 1_, T) and M = (M, !;::;, u, n, 1_, T) are
complete lattices and M is finite then the three conditions
(i) 'Y : M --+ L is monotone,

(ii) 'Y(T) = T, and
(iii) 1(m 1 n m2) = 'Y(ml) n 1(m2) whenever m 1 g m2 1\ m2 g m 1
are jointly equivalent to 'Y : M --+ L being completely multiplicative. •
Proof First note that if 'Y is completely multiplicative then (i), (ii) and (iii) hold.
For the converse note that by monotonicity of"'( we have 7(m1nm2) = 1(m1)n"Y(m2)
also when m1 [;;:; m2 V m2 [;;:; m1. We then prove by induction on the (finite)
cardinality of M' ~ M that:
(A.2)
If the cardinality of M' is O then (A.2) follows from (ii). If the cardinality of M' is
larger than O then we write M' = M" U {m"} where m" f:_ M"; this ensures that
the cardinality of M" is strictly less than that of M'; hen ce:
"Y((IlM") n m")
"Y(I-IM") n 1(m")
(1-1 {"Y(m) m E M"}) n "Y(m")
1
1-lh(m) m E M'}
1
This proves the result.

•
Lemma A.5 A function f : (P(D), ~) --+ (P(E), ~) is affine if and only
if there exists a function 'P : D --+ P(E) and an element 'P0 E P(E) such that
f(Y) = U{'P(d) 1 dE Y} U 'P0

The function f is completely additive if and only if additionally 'P0 = 0. •
A.2 Construction of Complete Lattices 397
Proof Suppose that f is of the form displayed and let Y be a non-empty set; Then
UU(Y) y E Y}
1 u{u{'P(d) 1 dE Y} U 'P0 1 Y E Y}
U{U{'P(d) 1 dE Y} 1 Y E Y} U 'P0
u{'P(d) 1 dE uY} u 'P0
f(UY)
showing that f is affine.

Next suppose that fis affine and define 'P(d) = f({d}) and 'P0 = !(0). For
Y E P(D) let Y = {{d} dE Y} U {0} and note that Y = UY and Y =10. Then
1
J(Y) J(UY)
u({f({d}) 1 dE Y} U {!(0)})
u({'P(d)) 1 dE Y} U {'P0})
u{'P(d) 1 dE Y} U 'P0
so f can be written in the required form. The additional statement about com-
pletely additivity is straightforward. •
An isomorphism from a partially ordered set (L1, ~1) to a partially ordered

set (L 2, ~ 2 ) is a monotone function (} : L1 - t L2 such that there exists a
(necessarily unique) monotone function o- 1 : L 2 - t L 1 with (}o o- 1 = id 2
and o- 1 o(}= id 1 (where idi is the identity function over Li, i = 1, 2).
A.2 Construction of Complete Lattices

Complete lattices can be combined to construct new complete lattices. We
shall first see how to construct products and then two kinds of function spaces.
Cartesian product. Let L1 = (L1. ~1) and L2 = (L2, ~2) be partially

ordered sets. Define L = (L, ~) by
and
(ln, l21) ~ (h2, l22) iff ln ~1 h2 1\ h1 ~2 b
It is then straightforward to verify that L is a partially ordered set. If ad-
ditionally each Li = (Li, ~i, Ui, ni, .li, Ti) is a complete lattice then so is
L = (L, ~, U,n, .l, T) and furthermore
and ..l = (..l1, ..l2) and similarly for nY and T. We often write L1 x L2 for
L and call it the cartesian product of L1 and L 2 .
A variant of the cartesian product called the smash product is obtained if we
require that all the pairs (h, b) of the lattice satisfy h = ..l1 {:} l2 = ..l2.
Total function space. Let L 1 = (L 1 , ~ 1 ) be a partially ordered set

and let S bea set. Define L = (L, ~) by
L = {! : S ---t L1 1 f is a total function}

and
f ~ !' iff Vs E S: f(s) ~1 /'(s)
It is then straightforward to verify that L is a partially ordered set. If
additionally L1 = (L1, ~ 1, U 1, n 1, ..l1, T 1) is a complete lattice then so is
L = (L, ~. U, n, ..l, T) and furthermore
UY = .>.s.Ul{J(s) 1 f E Y}
and ..l = .>.s ...l1 and similarly for nY and T. We often write S ---t L 1 for L
and call it the total function space from S to L 1 .
Monotone function space. Again let L 1 = (L1, ~ 1 ) and L 2

(L2, ~2) be partially ordered sets. Now define L = (L, ~) by
L = {f : L1 ---t L2 1 f is a monotone function}

and
f ~ f' iff Vh E L1: /(h) ~2 J'(h)
It is then straightforward to verify that L is a partially ordered set. If ad-
ditionally each Li = (Li, ~i, Ui, ni, ..li, Ti) is a complete lattice then so is
L = (L, ~. U,n, ..l, T) and furthermore
UY = .Xh.Ud!(h) 1f E Y}
and ..l = .Xh ...l2 and similarly for nY and T. We often write L1 ---t L2 for L
and call it the monotone function space from L1 to L2.
A.3 Chains
The ordering ~ on a complete lattice L = (L, ~) expresses when one prop-
erty is better (or more precise) than another property. When performing a
program analysis we will typically construct a sequence of elements in L and
it is the general properties of such sequences that we shall study now. In the
next section we will be more explicit and consider the sequences obtained
during a fixed point computation.
A.3 Chains 399
Chains. A subset Y <;;; L of a partially ordered set L = (L, [;;;) is a chain

if
Vh, b E Y: (h [;;; b) V (l2 [;;; h)
Thus a chain is a (possibly empty) subset of L that is totally ordered. We
shall say that it is a finite chain if it is a finite subset of L.
A sequence (ln)n = (ln)nEN of elements in L is an ascending chain if
Writing (ln)n also for {ln 1 nE N} it is clear that an ascending chain also is
a chain. Similarly, a sequence (ln)n is a descending chain if
and clearly a descending chain is also a chain.

We shall say that a sequence (ln)n eventually stabilises if and only if
3no E N : Vn E N : n ~ no =} ln = ln 0
For the sequence (ln)n we write Un ln for U{ln 1 n E N} and similarly we

write nnln for n{tn 1 nE N}.
Ascending Chain and Descending Chain Conditions. We

shall say that a partially ordered set L = (L, [;;;) has finite height if and only
if all chains are finite. It has finite height at most h if all chains contain at
most h + 1 elements; it has finite height h if additionally there is a chain with
h + 1 elements. The partially ordered set L satisfies the Ascending Chain
Condition if and only if all ascending chains eventually stabilise. Similarly, it
satisfies the Descending Chain Condition if and only if all descending chains
eventually stabilise. These concepts are related as follows:
Lemma A.6 A partially ordered set L = (L, [;;;) has finite height if and
only if it satisfies both the Ascending and Descending Chain Conditions. •
Proof First assume that L has finite height. If (ln)n is an ascending chain then it
must be a finite chain and hence eventually stabilise; thus L satisfies the Ascending
Chain Condition. In a similar way it is shown that L satisfies the Descending Chain
Condition.
Next assume that L satisfies the Ascending Chain Condition as well as the Descend-
ing Chain Condition and consider a chain Y ~ L. We shall prove that Y is a finite
chain. This is obvious if Y is empty so assume that it is not. Then also (Y, !;;;;) is
a non-empty partially ordered set satisfying the Ascending and Descending Chain
Conditions.
As an auxiliary result we shall now show that
each non-empty subset Y' of Y contains a least element (A.3)

• o 1• 00
• -1
• -2 • 2
• 1
1._00 • o
(a) (b)
Figure A.2: Two partially ordered sets.
To see this we shall construct a descending chain (l~)n in Y' as follows: first let l~
be an arbitrary element of Y'. For the inductive step let l~+ 1 = l~ if l~ is the least
element of Y'; otherwise we can find l~+ 1 E Y' such that l~+ 1 !;;; l~ 1\ l~+ 1 "Il~.
Clearly (l~)n is a descending chain in Y; since Y satisfies the Descending Chain
Condition the chain will eventually stabilise, i.e. 3n~ : Vn ~ n~ : l~ = l~, and the
o
construction is such that l~, is the least element of Y'.
o
Returning to the main proof obligation we shall now construct an ascending chain
(ln)n in Y. Using (A.3) each ln is chosen as the least element of the set Y \
{lo, · · ·, ln-1} as long as the latter set is non-empty, and this yields ln-1 !;;; ln 1\
ln-1 "lln; when Y \ {lo, · · ·, ln-1} is empty we set ln = ln-1, and since Y is non-
empty we know that n > O. Thus we have an ascending chain in Y and using the
Ascending Chain Condition we have 3no : \In ~ no : ln = ln 0 • But this means that
Y \ {lo, · · ·, ln 0 } = 0 since this is the only way we can achieve that lno+1 = ln 0 • It
follows that Y is finite. •
Example A. 7 The partially ordered set of Figure A.2 (a) satisfies the
Ascending Chain Condition but does not have finite height; the partially
ordered set of Figure A.2 (b) satisfies the Descending Chain Condition but
does not have finite height. •
One can show that each of the three conditions finite height, ascending chain,
and descending chain, is preserved under the construction of cartesian prod-
uct: if L1 and L2 satisfies one of the conditions then L1 x L2 will also satisfy
that condition. The construction of total function spaces S --+ L only pre-
serves the conditions of L if S is finite and the construction of monotone
function spaces L1 --+ L2 does not in general preserve the conditions.
An alternative characterisation of complete lattices satisfying the Ascending
Chain Condition is given by the following result:
A.3 Chains 401
Lemma A.8 For a partially ordered set L = (L, ~) the conditions
(i) L is a complete lattice satisfying the Ascending Chain Condition, and

(ii) L has a least element, .l, and binary least upper bounds and satisfies
the Ascending Chain Condition
are equivalent. •
Proof It is immediate that (i) implies (ii) so let us prove that (ii) implies (i). Using
Lemma A.2 it suffices to prove that all subsets Y of L have a least upper bound
UY. If Y is empty clearly UY = .l. If Y is finite and non-empty then we can
U
write Y = {y1, · · ·, Yn} for n ~ 1 and it follows that Y = (· · · (y1 Uy2) U · · ·) Uyn.
If Y is infinite then we construct a sequence (ln)n of elements of L: let la be an
arbitrary element yo of Y and given ln take ln+l = ln in the case where Vy E Y : y [;;;;
ln and take ln+l = ln U Yn+l in the case where some Yn+l E Y satisfies Yn+l lb ln.
Clearly this sequence is an ascending chain. Since L satisfies the Ascending Chain
Condition it follows that the chain eventually stabilises, i.e. there exists n such that
ln = ln+l = · · ·. This means that Vy E Y : y [;;;; ln because if y lb ln then ln =1- ln U y
and we have a contradiction. So we have constructed an upper bound for Y. Since
it is actually the least upper bound of the subset {yo, · · ·, Yn} of Y it follows that
it is also the least upper bound of Y. •
A related result is the following:
Lemma A.9 For a complete lattice L = (L, ~) satisfying the Ascending

Chain Condition and a total function f : L ---t L, the conditions
(i) fis additive, i.e. Vh, 12 : /(h U 12) = f(h) U J(l2), and
(ii) f is affine, i.e. VY ~ L, Y =1- 0 : /(U Y) = U{!(l) Il E Y}
are equivalent and in both cases f is a monotone function. •

Proof It is immediate that (ii) implies (i): take Y = {h, b}. It is also immediate
that (i) implies that f is monotone since h [;;;; l2 is equivalent to h U l2 = l2.
Next suppose that f satisfies (i) and let us prove (ii). If Y is finite we can write
Y = {y1, · · · , Yn} for n ~ 1 and
f(U Y) = f(Yl u ... u Yn) = f(y!) u ... u f(yn) [;;;; UU(l) Il E Y}

If Y is infinite then the construction of the proof of Lemma A.8 gives UY = ln
and ln = Yn U · · · Uyo for some Yi E Y and O::::; i::::; n. We then have
f(U Y) = f(ln) = f(yn u · · · u Yo) = f(yn) u · · · u f(yo) [;;;; UU(l) Il E Y}

Furthermore
f(u Y) ;;;) uu(l) Il E Y}
follows from the monotonicity of f. This completes the proof. •
A.4 Fixed Points

Reductive and extensive functions. Consider a monotone func-
tion f : L--+ L on a complete lattice L = (L, ~' U, n, .l, T). A fixed point of
f is an element l E L such that f(l) = l and we write
Fix(!)= {li f(l) = l}
for the set of fixed points. The function f is reductive at l if and only if
f(l) ~ l and we write
Red(f) = {l f(l) ~ l}1
for the set of elements upon which f is reductive; we shall say that f itself
is reductive if Red(f) = L. Similarly, the function f is extensive at l if and
only if f(l) ;;::1 l and we write
Ext(f) ={li f(l) ;;::1 l}
for the set of elements upon which f is extensive; we shall say that f itself is
extensive if Ext(f) = L.
Since L is a complete lattice it is always the case that the set Fix(!) will
have a greatest lower bound in L and we denote it by lfp(f):
lfp(f) = n Fix(!)
Similarly, the set Fix(!) will have a least upper bound in L and we denote it
by gfp(f):
gfp(f) = U
Fix(!)
We then have the following result, known as Tarski's Fixed Point Theorem,
showing that lfp(f) is the least fixed point of f and that gfp(f) is the greatest
fixed point of f:
Proposition A.lO
Let L = (L, ~' U,n, .l, T) bea complete lattice. If f: L--+ Lis
a monotone function then lfp(f) and gfp(f) satisfy:
lfp(f) nRed(f) E Fix(!)

gfp(f) UExt(f) E Fix(!)
Proof To prove the claim for Jfp(f) we detine lo = nRed(f). We shall first show
that f(lo) [;;; lo so that lo E Red(f). Since l0 [;;; l for ali l E Red(f) and f is
monotone we have
f(lo) [;;; f(l) [;;; l for alll E Red(f)
A.4 Fixed Points 403
r(T)
Red(f)- - - -
• nnr(T)
gfp(f)
lfp(f)
Un rCl)
Ext(f) - - - -
- ...... -
r(l-)
l_
Figure A.3: Fixed points of f.
and hence f(lo) r;;;; lo. To prove that lo r;;;; f(lo) we observe that f(f(lo)) r;;;; f(lo)
showing that f(lo) E Red(f) and hence lo r;;;; f(lo) by definition of lo. Together this
shows that lo is a fixed point of f so lo E Fix(!). To see that lo is least in Fix(!)
simply note that Fix(!) t;;; Red(f). It follows that lfp(f) = lo.
The claim for gfp(f) is proved in a similar way. •
In denotational semantics it is customary to iterate to the least fixed point by
taking the least upper bound of the sequence (fn (l_)) n. However, we have not
imposed any continuity requirements on f (e.g. that f (Un ln) = Un (f (ln))
for all ascending chains (ln)n) and consequently we cannot be sure to actually
reach the fixed point. In a similar way one could consider the greatest lower
bound of the sequence (r(T))n· One can show that
l_ ~ r(l_) ~ Unr(l_) c:: lfp(f)

C:: gfp(f) ~ nnf~(T) ~ r(T) ~ T
as is illustrated in Figure A.3; indeed all inequalities (i.e. ~) can be strict

(i.e. c::). However, if L satisfies the Ascending Chain Condition then there
exists n such that r (l_) = r+ 1 ( l_) and hen ce lfp(f) = r (l_). (Indeed any
monotone function f over a partially ordered set satisfying the Ascending
Chain Condition is also continuous.) Similarly, if L satisfies the Descending
Chain Condition then there exists n such that r(T) = r+ 1 (T) and hence
gfp(f) = r(T).
Remark (for readers familiar with ordinal numbers). It is possible always

to obtain lfp(f) as the limit of an ascending (transfinite) sequence but one
may have to iterate through the ordinals. To this effect define Ji"' E L for
an ordinal K, by the equation
and note that for a natural number n we have Jln = r+l(..L). Then lfp(f) =
Ji"' whenever K, is a cardinal number strictly greater than the cardinality of
L, e.g. K, may be taken tobe the cardinality of P(L). A similar construction
allows to obtain gfp(f) as the limit of a descending (transfinite) chain. •
Concluding Remarks
For more information on partially ordered sets consult a text book (e.g. [43]).
Appendix B
Ind uction and Coind uction
We begin by reviewing a number of techniques for conducting inductive

proofs. We then motivate the concept of coinduction and finally formulate
a general proof principle for coinduction. This makes heavy use of Tarski's
Fixed Point Theorem (Proposition A.10).
B.l Proof by Induction

Mathematical induction. Perhaps the best known induction princi-
ple is that of mathematical induction. To prove that a property, Q(n), holds
for all natural numbers, n, we establish
Q(O)
't:/n: Q(n) =? Q(n + 1)
and conclude
't:/n: Q(n)
Formally, the correctness of mathematical induction can be related to the fact
that each natural number is either O or the successor, n + 1, of some other
natural number, n. Thus the proof principle reftects the way the natural
numbers are constructed.
Structural induction. Mathematical induction allows us to perform

induction on the size of any structure for which a notion of size can be defined;
this is just a mapping from the structure into the natural numbers. As an
example consider an algebraic data type given by
dED
d ::= Base 1 Con1(d) 1 Con2(d, d)
406 B Induction and Coinduction
where Base is a base case, Con 1 is a unary constructor and Con 2 is a binary
constructor. To prove that a certain property, Q(d), holds for all elements,
d, of D we can define a size measure:
size(Base) o
size( Con 1(d)) 1 + size(d)
size(Con2(d1, d2)) 1 + size( d1) + size( d2)
and then proceed by mathematical induction on size(d) to prove Q(d).
Alternatively we can conceal the mathematical induction within a principle
of structural induction: we must then show
Q(Base)
\:/d: Q(d) =:;. Q(Con 1(d))
\:/d1, d2: Q(dl) A Q(d2) ==? Q(Con2(d1, d2))
from which we conclude

\:/d: Q(d)
Once again the proof principle reflects the way the data are constructed.
lnduction on the shape. Now suppose that Base represents O, that

Con 1(d) represents d + 1, and that Con2(d1,d2) represents d1 + d2. We can
then define a Natur al Semantics
d-+n
for evaluating d into the number, n, it represents:

[base] Base-+ O
Con1(d)-+ n+ 1
d1 -+ n1 d2 -+ n2
Con2(d1, d2)-+ n1 + n2
This defines a notion of evaluation trees, d ~ n: there is one base case

([base]) and two constructors ([con!] and [con 2]). Again we can perform
induction on the size of the evaluation trees but as above it is helpful to
conceal the mathematical induction within a principle of induction on the
shape of inference trees: we must show
Q(Base-+ O)
V V d-+n
V )
\:/(d-+ n): Q(d-+ n) =:;. Q ( Con1(d)-+n + 1
B.2 Introducing Coinduction 407

V(d .:S n) : Q(d .:S n)
As is tobe expected, the proof principle once again reflects the way evaluation
trees are constructed.
Course of values induction. All of the above induction principles

have been constructive in the sense that we establish a predicate for the base
cases and then show that it is maintained by all constructors. A variant of
mathematical induction with a different flavour requires proving
Vn: (Vm < n: Q(m)) ==} Q(n)
Vn: Q(n)
Here the base case is dealt with in the same manner as the induction step.
This induction principle is called course of values induction.
Well-founded induction. Course of values induction is an instance

of a very powerful induction principle called well-founded induction. Given a
partially ordered set (D, :::5), the partial ordering is a well-founded ordering
if there is no infinite decreasing sequence
dl >- d2 >- d3 >- ...
where d >- d' means d' :::5 d 1\ d -::f d' - this amounts to the Descending Chain
Condition studied in Appendix A. The principle of well-founded induction
then says: if we show
Vd: (Vd' -< d: Q(d')) '* Q(d)
we may then conclude
Vd: Q(d)
(The proof of correctness of this principle is along the lines of the proof of
(A.3) in Lemma A.6 and can be found also in the literature referenced below.)
B.2 Introducing Coind uction

To explain the difference between induction and coinduction, and to motivate
the need for coinductive methods, let us consider a small example. Consider
the program
if /(27, m) then "something good" else "something bad"
where f is a function from pairs of natural numbers (i.e. pairs of non-negative

integers) to truth values.
We want to ensure that the program never undertakes to do "something
bad" . Since the value of m is not known it is not feasible to prove that
/(27, m) #-false by merely evaluating /(27, m); we therefore need to perform
some kind of proof. For this it is natural to define the predicate Qf as follows
Qt(n) iff Vm : f(n, m) #-false
where it is implicit that m, n 2: O.

Perhaps the most obvious approach is to use mathematical induction to prove
't:/n: Qt(n). This amounts to proving
Qt(O)
't:/n: Qt(n) =} Qt(n + 1)
and then concluding
't:/n: Qt(n)
from which the desired Qt(27) follows.
An alternative presentation of essentially the same idea is to establish the
validity of the axiom and rule
and then deduce that

't:/n: Qt(n)
Here the basic steps in the mathematical induction have been couched in
terms of an inductive definition of the predicate Qf.
The approach outlined above works nicely for the function fo defined by
fo(O,m) true
fo(n + l,m) fo(n,m)
but what about the functions Il, h and /3 defined by
!l(O,m) !l(O,m) h(O,m) true

h(n + l,m) JI(n,m) h(n+ l,m) h(n + l,m)
/3(0,m) h(O,m)
h(n + l,m) h(n+ l,m)
B.2 Introducing Coinduction 409
where fi(27, m) never terminates? Intuitively, they should be acceptable in

the sense that "something bad" never happens. However, we cannot prove
this by induction because we cannot establish the base case (for fi and h)
and/or we cannot establish the inductive step (for h and h).
An intuitive argument for why fi is acceptable might go as follows: assume
that all occurrences of fi on the right hand sides of the above definitions
satisfy Qi; then it follows that also the fi on the left hand side does. Hence
fi satisfies Qi, i.e. 'Vn : Qi(n). This sounds very dangerous: we assume the
desired result in order to prove it. However, with due care and given the
proper definition of Qi, this is a valid proof: it is a coinductive proof.
Obtaining a functional. Let us rewrite the defining clauses of fi into

clauses for Qi so as to clarify the relationship between when Qi holds on the
left hand side and on the right hand side of the definitions of fi:
Q0 (0) iff true Ql (O) iff Ql (O)
Qo(n + 1) iff Qo(n) Q1(n + 1) iff Q1(n)
(B.1)
Q2(0) iff true Q3(0) iff Q3(0)
Q2(n + 1) iff Q2(n + 1) Q3(n + 1) iff Q3(n + 1)
Here the clauses for Q0 look just like our principle for mathematical induction
whereas the others involve some amount of circularity. To make this evident
let us rewrite the above as
Qi = Qi(Qi) (B.2)
where
Qo(Q')(O) true Ql(Q')(O) Q'(O)
Qo(Q')(n + 1) Q'(n) Ql(Q')(n + 1) Q'(n)
(B.3)
Q2(Q')(O) true Q3(Q')(O) Q'(O)
Q2(Q')(n + 1) Q'(n + 1) Q3(Q')(n + 1) Q'(n + 1)
Clearly Qi satisfies (B.1) if and only if it satisfies (B.2) with Qi as in (B.3).
It is immediate that each Qi is a monotone function on the complete lattice
(N -+ { true,false}, [;;;)
of predicates where Q 1 [;;; Q2 means that 'Vn: Q1 (n) =? Q2(n) and where the
least element .1 is given by 'Vn : ..l(n) =false and the greatest element T is
given by 'Vn: T(n) = true. Using Tarski's Fixed Point Theorem (Proposition
A.10) it follows that each Qi has a least fixed point lfp(Qi) and a greatest
fixed fixed point gfp( Qi); these are possibly different predicates in (N -+
{ true, false},[;;;).
We frequently refer to Qi as a functional by which we mean a function whose
argument and result are themselves functions (or that are more elaborate
structures containing functions in them).
410 B lnduction and Coinduction
Least fixed point. Let us begin by looking at the least fixed points.
It follows from Appendix A that
and given that the clauses for Qo(Q) only use a finite number of Q's on the
right hand sides (in fact zero or one), Q0 satisfies a continuity property that
ensures that
This is good news because our previous proof by mathematical induction

essentially defines the predicate ukQâ(..l): Qâ(..l)(n) holds if and only if at
most k axioms and rules suffice for proving Qo (n). Thus it would seem that
a proof by induction "corresponds" to taking the least fixed point of Q0 •
Next let us look at Q3. Here
because Q3(..l) = ..l so that ..l is a fixed point. This explains why we have
Jfp(Q3)(27) =false and why an inductive proofwill not work for establishing
Q3(27). Somewhat similar arguments can be given for Ql and Q2.
Greatest fixed point. Let us next look at the greatest fixed points.
Here
because Q3(T) = T so that T is a fixed point. This explains why we have

g.tp(Q3)(27) = true and thus provides a formal underpinning for our belief
that h will not cause any harm in the example program. Somewhat similar
arguments can be given for Ql and Q2.
Also for Q 0 it will be the case that g.tp(Q 0 )(27) = true. This is of course
not surprising since Jfp(Qo)(27) = true and l.tp(Qo) ~ g.tp(Qo). However,
it is more interesting to note that for Q0 there is no difference between the
inductive and the coinductive approach (unlike what is the case for Q1, Q2
and Q3):
lfp( Qo) = g.tp( Qo)
because mathematical induction on n suffices for proving that lfp(Qo)(n) =

g.tp( Qo)(n ).
Remark. To the mathematically inclined reader we should point out that
the fact that l.tp(Q 0 ) = g.tp(Q 0 ) is related to Banach's Fixed Point Theorem:
a contractive operator on a complete metric space has a unique fixed point.
Contractiveness of Qo (as opposed to Q1, Q2 and Q3) follows because the
clause for Q 0 (Q)(n) only performs calls to Q on arguments smaller than n. •
B.3 Proof by Coinduction

Consider once again the algebraic data type
dED
d ::= Base 1 Con1(d) 1 Con2(d, d)
with one base case, one unary constructor and one binary constructor. Next
consider the definition of a predicate
Q: D --+ { true, false}
by means of clauses of the form:
Q(Base) iff
Q(Con1 (d)) iff · · · Q(d') · · ·
Q(Con2(d1, d2)) iff · · · Q(d~) · · · Q(d~) · · ·
We can use this as the hasis for defining a functional Q by cases as in:
Q(Q')(Base)
Q(Q')(Con1(d)) = ... Q'(d') .. .
Q(Q')(Con2(d1, d2)) ... Q'(d~) ... Q'(d~) ...
We note that
(D --+ { true,false}, !::;;)
is a complete lattice under the ordering given by Q1 !::;; Q2 if and only if
\/d: Q1 (d) :::} Q 2(d). We also
assume that Q is monotone
and this means that e.g. a clause like "Q(Con1(d)) iff •Q(d)" will not be
acceptable. From Proposition A.lO it follows that Q has a least as well as a
greatest fixed point.
Induction (or least fixed point). Consider first the inductive def-
inition:
Q = lfp(Q) (B.4)
This is more commonly written as:
.. ·Q(d') ... . .. Q(d~) ... Q(d;) ...
(B.5)
Q(Base) Q(Con1(d)) Q(Con2(d1, d2))
It is often the case that each rule only has a finite number of calls to Q
and then the two definitions are equivalent: the predicate in (B.5) amounts
412 B lnduction and Coinduction
to uk Qk ( j_) and by a continuity property as discussed above, this agrees

with the predicate of (B.4). A proof by induction then simply amounts to
establishing the validity of the axioms and rules in (B.5). Such a proof has a
very constructive fiavour: we take nothing for granted and only believe what
can be demonstrated to hold. This proof strategy is often used to reason
about semantics because the semantics of a program should not allow any
spurious behaviour that is not forced by the semantics.
Coinduction (or greatest fixed point). Consider next the coin-

ductive definition
Q = gfp(Q)
A proof by coinduction then amounts to using the proof rule
Q' [;;;; Q(Q') Q' [;;;; Q(Q'))

(.
Q'[;;;;Q 1.e. Q' [;;;; gfp( Q)
as follows from the formula for g.tp(Q) given in Proposition A.lO. So to prove
Q(d) one needs to
find some Q' such that

Q'(d)
Vd': Q'(d')::::} Q(Q')(d')
Such a proof has a very optimistic fiavour: we can assume everything we like
as long as it cannot be demonstrated that we have violated any facts. It is
commonly used for checking that a specification holds because the specifica-
tion should not forbid some behaviour unless explicitly called for.
It sometimes saves a bit of work to use the derived proof rule
Q' [;;;; Q(QUQ')

Q'[;;;;Q
To see that this is a valid proof rule suppose that Q' [;;;; Q(Q U Q'). By
definition of Q we also have Q [;;;; Q(Q) and by monotonicity of Q this gives
Q [;;;; Q(Q U Q'). Hence
QuQ' [;;;; Q(QuQ')
and Q U Q' [;;;; Q follows by definition of Q. It is then immediate that Q' [;;;; Q
as required.
Clearly this explanation can be generalised to algebraic data types with ad-
ditional base cases and constructors, and from predicates to relations.
Example B.l Consider the relations

R1 : Du x D12 -t { true, false}
R2 : D21 x D22 -t { true, false}
defined by:
R1 = R1 (R1. R2)
R2 = R2(R1, R2)
This is intended to define
where R(R~,R~) = (R 1 (R~,R~), R2(R~,R~)) is assumed tobe monotone.

Next write R' U R" for the relation defined by
and write R' ~ R" for the truth value defined by:
We then have the following version of the coinduction principle: we establish
R'1 C: R1 (R~, R~)

R~ c: R2(R~, R~)
and conclude:
R~ ~ R1 and R~ ~ R2
By analogy with the previous discussion, it sometimes saves a bit of work
only to show
R~ C: R1(R1 U R~, R2 U R~)

R~ C: R2(R1 U R~, R2 U R~)
because we also have

R1 C: R1(R1, R2) C: R1(R1 U R~, R2 U R~)
R2 C: R2(R1,R2) C: R2(R1UR~,R2UR~)
and this allows us to conclude
using the definition of (R1. R2) = gfp(R). •

Example B.2 For an example of a somewhat different flavour consider

the universe
{0, 1, 2} 00 = {0, 1, 2}* U {0, 1, 2}w
where {0, 1, 2}* consists of finite strings (ai)i=l = a 1 ···an of symbols ai E
{0, 1, 2} and where {0, 1, 2}w consists of infinite strings (ai)~ 1 = a 1 ···an···
of symbols ai E {0, 1, 2}. Concatenation of strings is defined as follows
(c )n+m ak ifk::;n
(ai)i=l (bj)'j=l k k=l where Ck = {
bk-n if k > n
ak ifk::;n
(ai)i=l (bj )'t=l (ck)~l where Ck = {
bk-n if k > n
(ai)~l (bj)j·~l (ck)~l where Ck = ak
(where · · · denotes "m" or "oo" in the last formula).

Next consider a context free grammar with start symbol S and productions:
S--+OI1IOSI1S
It can be rephrased as an inductive definition
xES xES
OES 1E S
Ox E S 1x E S
for defining a subset S ~ {0, 1, 2} 00 • If an inductive interpretation is taken,

as is usually the case for context free grammars, the set S is {0, 1} + that
consists of all strings (ai)i=l that are finite and nonempty (so n > O) and
without any occurrence of 2's (i.e. ai E {0, 1} ).
If a coinductive interpretation is taken the set S becomes {0, 1} + U {0, 1}w
where also all infinite strings of O's and l's occur. To see this note that the
empty string cannot be in S because it is not of one of the forms O, 1, Ox or
lx. Also note that no string containing 2 can be in S: a string containing
2 can be written a 1 · · · an2x where ai E {0, 1} and we proceed by induction;
for n = O the result is immediate (since none of O, 1, Ox or 1x starts with a
2) and for n >O we note that if a1 · · · an2x E S then a2 · · · an2x E S and by
the induction hypothesis this cannot be the case. Finally note that there is
no way to exclude infinite strings of O's and 1's to be in S because they can
always be written in one of the forms Ox or 1x (where x E {0, l}w).
Now suppose we add the production
S--+S
corresponding to the rule:

xES
xES
When interpreted inductively this does not change the set S; it is stiH {0, 1} +.
However, when interpreted coinductively the set S changes dramatically; it is
now {0, 1, 2} 00 and thus includes the empty string as well as strings containing
2. To see this simply note that any string x in {0, 1, 2} 00 can be written as
x = x and hence no string can be excluded from being inS. •
Concluding Remarks
For more information on induction principles consult a text book (e.g. [16]).
It is harder to find good introductory material on coinduction; one possibility
is to study the work on strong bisimulation in CCS (e.g. Chapter 4 of [106]).
Appendix C
Graphs and Regular

Expressions
C.l Graphs and Forests

Directed graphs. A directed graph (or digraph) G = (N, A) consists of
a finite set N of nodes (or vertices) and a set A ~ N x N of edges (or arcs).
An edge (n1, n2) has source n1 and target n2 and is said to go from n1 to
n 2 ; if n1 = n 2 it is a self-loop. We shall sometimes refer to a directed graph
simply as a graph.
A directed path (or just path) from a node no to a node nm is a sequence
of edges (no, n1), (n1,n2), · · ·, (nm-2, nm-1), (nm-1, nm) where the target of
the edge (ni-l> ni) equals the source of the edge (ni, ni+t). The path is said
to have source no, target nm and length m ~O; if m =O the path is said tobe
trivial and then consists of the empty sequence of edges. The concatenation of
the path (no, n1), · · ·, (nm-1, nm) with the path (nm, nm+l), · · ·, (nk-1, nk) is
the path (no, nt), · · ·, (nk-1, nk)· We say that n' is reachable from n whenever
there is a (possibly trivial) directed path from n ton'.
Example C.l Let S bea statement from the WHILE language of Chapter
2. The forward flow graph (Jabels(S), How(S)) and the backward flow graph
(labels(S),Ho~(S)) are both directed graphs. Next let Lab bea finite set
of labels and F ~ Lab x Lab a flow relation in the manner of Section 2.3.
Then G = (Lab, F) is a directed graph. •
Example C.2 Let e* be a program in the FuN language of Chapter 3 and

let N* be the finite set of nodes p of the form C(f) or r(x) where .eE Lab* is
a labei in the program and x E Var* is a variable in the program. Let C be
418 C Graphs and Regular Expressions
a set of constraints of the form considered in Section 3.4 and let A* contain
the edge (PI.P2) for each constraint P1 ~ P2 in C and the edges (p,p2) and
(p1,P2) for each constraint {t} ~ p::::} P1 ~ P2 in C. Then G = (N*,A*) is a
directed graph. •
In keeping with the notation used in Chapter 2 we shall usually write a

path p = (no, nl), (n1, n2), · · ·, (nm-2, nm-d, (nm-1, nm) as the sequence
p = [no, n1, n2, · · ·, nm-2, nm-1, nm] of nodes visited. In this notation the
sequence of nodes is never empty and the trivial path from no to no is
written [no] whereas a self-loop is written [no, no]. The concatenation of
the path [no, n1, · · ·, nm-b nm] with the path [nm, nm+l, · · ·, nk-1, nk] is the
path [no, n1, · · ·, nk-1, nk] (where nm does not occur twice).
We shall define the set of paths from n to n' as follows:
paths.(n, n') = {[no, · · ·, nm] 1 m 2:: O 1\ no = n 1\ nm = n' 1\

Vi< m: (ni,ni+l) EA}
Cycles. A cycle is a non-trivial path from a node to itself (and may take
the form of a self-loop); the set of cycles from a node n to itself is defined as
follows:
cycles(n) = {[no, · · ·, nm] 1 m 2:: 1 1\ no = n 1\ nm =n 1\
Vi< m: (ni, ni+1) EA}
and we observe that cycles(n) = {p E paths.(n, n) 1 p =f [n]}. A cycle

p = [n0, n 1, · · ·, nm] is multiple entry if it contains two distinct nodes (not
merely distinct indices), ni =f nj, such that there are (not necessarily distinct)
nodes n~ and nj external to the cycle with (n~, ni), (nj, nj) EA.
A graph that contains no cycles (so Vn E N : cycles(n) = 0) is said to be
acyclic. A directed, acyclic graph is often called a DAC.
A topological sort of a directed graph is a total ordering of the nodes such
that if (n, n') is an edge then n is ordered strictly before n'. A directed graph
has a topologica! sort if and only if it is acyclic.
Strongly connected components. Two nodes n and n' are said

tobe strongly connected whenever there is a (possibly trivial) directed path
from n to n' and a (possibly trivial) directed path from n' to n. Defining
se = {(n, n') 1 n and n' are strongly connected}
we obtain a binary relation se~ N X N.
Fact C.3 se is an equivalence relation. •

Proof Reflexivity follows from the fact that there is a trivial path from any node
to itself. Symmetry follows immediately from the definition. Transitivity follows
C.l Graphs and Forests 419
from observing that if P12 is a path from n1 to n2 and P23 is a path from n2 to n3
then P12P23 is a path from n1 to n3. •
The equivalence classes of SC are called the strong components (or strongly
connected components) of the graph G = (N, A). A graph is said to be
strongly connected whenever it contains exactly one strongly connected com-
ponent.
Example C.4 In uniquely labelled statements of the WHILE language of

Chapter 2, the nodes corresponding to the outermost loop in any nested
sequence of loops would constitute a strongly connected component; this is
true for both forward and backward flow graphs. •
The interconnections between strong components can be represented by the

reduced graph. Each strongly connected component is represented by a node
in the reduced graph and there is an edge from one node to another distinct
node if and only if there is an edge from some node in the first strongly
connected component to a node in the second in the original graph. Hence,
the reduced graph contains no self-loops.
Lemma C.5 For any graph G the reduced graph is a DAG. •

Proof Suppose, by way of contradiction, that the reduced graph contains a cycle
[SCo, · · ·, SCm] where SCm = SCo. Since we already observed that the reduced
graph contains no self-loops this means that the cycle contains distinct nodes SC;
and SCi and we may without loss of generality assume that i < j.
That there is an edge from SCk to SCk+l in the reduced graph (O:::; k < m) means
that there is an edge (nk, n~+ 1 ) in the original graph from a node nk E SCk to a
node n~+l E SCk+l· It is also immediate that there is a path Pk in the original
graph from n~ to nk and a path p~ from n:n to no.
We can now construct a path (n;,n~+ 1 )Pi+l" · · (nj-1,nj)pi in the original graph
from n; to ni and a path (nj, nj+l)Pi+l · · · (nm-1, n:n)p~(no, nDp1 ···(ni-l, n;)p;
from ni ton;. But then n; and ni should be in the same equivalence class thereby
contradicting our assumption that SC; # SCi. •
Handles and roots. A handle for a directed graph G = (N, A) is a

set H ~ N of nodes such that for all nodes n E N there exists a node h E H
such that there is a (possibly trivial) directed path from h to n. A root is
a node r E N such that for all nodes n E N there is a (possibly trivial)
directed path from r to n. If r is a root for G = (N, A) then {r} is handle
for G; in fact, {n} is a handle for G if and only if n is a root. Conversely,
if H is a handle for G = (N, A) and r fţ N then r is a root for the graph
(NU {r }, AU {(r, h) 1 h E H} ); we sometimes refer to r as a dummy root
and to each (r, h) as a dummy edge.
A directed graph G = (N, A) always has a handle since one can use H =Nas
the handle. A handle H is minimal if no proper subset is a handle, that is, if
H' C H then H' is not a handle. One can show that minimal handles always
exist since the set of nodes is finite. The minimal handle is a singleton if and
only if the graph has a root; in this case we say that the graph is rooted.
Example C.6 Let S bea statement from the WHILE language of Chap-
ter 2. Then init( S) is a root for (labels( S), flow( S)) and {init( S)} is a min-
imal handle. Furthermore, fi.nal(S) is a handle for the backward fl.ow graph
(labels( S), flo~ (S)). •
A path from a handle H to a node n is a path from a node h E H to n;

similarly for a path from the root r to a node n. Given a handle H, possibly
in the form of a root r (corresponding to H = {r}), the set of paths from H
to n is defined by:
path~ (n) = U{paths.(h, n) 1h E H}
When H is implicit we write path.(n) for path~ (n).
Forests and trees. A node n in a graph G = (N, A) is said to have

in-degree m if the set of predecessors, {n' 1 ( n', n) E A}, has cardinality m.
Similarly, one can define the concept of out-degree.
A forest (or unordered, directed forest) is a directed, acyclic graph G =
(N, A) where nodes have in-degree at most 1. One can show that the set
of nodes with in-degree O constitutes a minimal handle for the forest. If
(n, n') E A then n is said to be the parent of n' and n' is a said to be a
child of n; ancestor and descendant are the reflexive, transitive closures of
the parent and child relations, respectively. The node n is a proper ancestor
of n' if it is an ancestor and n -=f:. n' and similarly for proper descendants.
A tree (or unordered, directed tree) is a forest that has a root; in other words,
a tree is a forest where exactly one node has in-degree O and this is then the
root. Given a forest (N, A) with minimal handle H, each node h E H will be
a root for the tree consisting of all the nodes n E N reachable from h and all
the edges (n1, n2) E E whose source and target are both in the tree; thus a
forest can be viewed as a set of trees.
Sometimes we will be interested in ordered forests and ordered trees which
are forests and trees where additionally all children of a node are linearly
ordered (unlike what is normally the case for graphs, forests and trees).
Dominators. Given a directed graph G = (N, A) with handle H, possi-

bly in the form of a root r (corresponding to H = {r}), a node n' is said to
be a dominator of a node n whenever every (possibly trivial) path from H
to n contains n'. We also say that n' dominates n. As a consequence of the
C.2 Reverse Postorder 421
INPUT: A directed graph (N, A) with k nodes and handle H
OUTPUT: (1) A DFSF T = (N,Ar), and

(2) a numbering rPostorder of the nodes indicating the
reverse order in which each node was last visited
and represented as an element of array [N] of int
METHOD: i := k;
mark ali nodes of N as unvisited;
let Ar be empty;
while unvisited nodes in H exists do
choose a node h in H;
DFS(h);
USING: procedure DFS(n) is

mark n as visited;
while (n, n') E A and n' has not been visited do
add the edge (n, n') to Ar;
DFS(n');
rPostorder[n] := i;
i := i -1;
Table C.l: The DFSF Algorithm.
definition of paths, the only dominator of an element of a minimal handle

(such as a root) is the element itself.
For any node n the set of dominators can be specified as the greatest solution
to the following equation:
{n} ifn E H
Dom(n) = {
{n} U n{Dom(n') j (n', n) EA} otherwise
The node n' properly dominates the node n if the two nodes are distinct
and n' dominates n. The node n' directly dominates the node n if it is
the "closest" proper dominator of n; that is n' E Dom( n) \ {n} and for all
n" E Dom(n)\{n} we have n" E Dom(n').
C.2 Reverse Postorder

Spanning forests. A spanning forest for a graph is a forest, with the
same nodes as the graph and a subset ofthe edges of the graph (see below) as
Figure C.l: A flow graph.
edges. The algorithm of Table C.l non-deterministically constructs a depth-

first spanning forest (abbreviated DFSF). In parallel with constructing the
forest, the algorithm also generates a numbering of the nodes which is the
reverse of the order in which the nodes are last visited in the construction of
the tree; this ordering is called the reverse postorder and in the algorithm it
is represented as an array indexed by the nodes of the graph. If the DFSF is
a tree it is called a depth-first spanning tree (abbreviated DFST). Note that
the algorithm does not specify which unvisited node to select at each stage;
consequently, the depth-first spanning forest for a graph is not unique.
Given a spanning forest one can categorise the edges in the original graph as
follows:
• Tree edges: edges present in the spanning forest.
• Forward edges: edges that are not tree edges and that go from a node
to a proper descendant in the tree.
• Back edges: edges that go from descendants to ancestors (including

self-loops).
• Cross edges: edges that go between nodes that are unrelated by the
ancestor and descendant relations.
The algorithm of Table C.l ensures that cross edges always go from nodes
visited later (i.e. with lower numbers in the reverse postorder) to nodes visited
earlier (i.e. with higher numbers).
Example C. 7 To illustrate the operation of the algorithm, consider the

graph in Figure C.l with root b1 . The algorithm may produce the tree shown
C.2 Reverse Postorder 423
Figure C.2: A DFSF for the graph in Figure C.l.
in Figure C.2. The reverse postorder of the nodes is b1 , b3, 8 3, b2, 8 1 ,82 and
the second number annotating each node in Figure C.2 reflects this ordering.
The edges from 82 to b2 and from 83 to b3 in Figure C.l are back edges. The
edge from b3 to 81 is a cross edge. •
Example C.8 Let 8 bea uniquely labelled statement from WHILE and
consider the forward flow graph (labels(8), flow(8)) with root init(8). First
consider a while loop while b' do 8' in 8. It gives rise to one tree edge
and one or more back edges; more precisely as many back edges as there are
elements in fina1(8'). Next consider a conditiona! i f b' then 8~ else 8~ in 8
that is not the last statement of 8 and not the last statement of the body of a
while loop in 8. It gives rise to three tree edges and one or more cross edges;
more precisely there will be one fewer cross edges than there are elements in
fina1(8n U finaJ(8~). Note that no forward edges can arise for statements in
WHILE; however, an extension of WHILE with a one-branch conditiona! i f b
then 8 can give rise to forward edges. •
Properties. We now establish some properties of reverse postorder. The

first lemma shows that the node at the source of a back edge comes later than
the target (unless it is a self-loop).
Lemma C.9 Let G = (N, A) bea directed graph, Ta depth-first spanning

forest of G and rPostorder the associated ordering computed by the algorithm
of Table C.l. An edge (n, n') EA is a back edge if and only if rPostorder[n] ~
rPostorder[n'] and is a self-loop if and only if rPostorder[n] = rPostorder[n']. •
Proof The statement about self-loops is immediate. Next let (n, n') EA.
(===? ): If (n, n') is a back edge then n is a descendant of n' in T. Consequently, n'
is visited before n in the depth first search and the call DFS(n') is pending during
the entire call of DFS(n) and consequently rPostorder[n] ~ rPostorder[n'].
( ~ ): If rPostorder[n] ~ rPostorder[n'] then, either n is a descendant of n' or n' is

in a subtree that was constructed later than the subtree that n appears in. In the
second case, since (n, n') E A, it would be a cross edge going from a node with a
high reverse postorder number to a node with a low reverse postorder number -
since our algorithm does not admit such cross edges, n must be a descendant of n'
and thus (n, n') is a back edge. •
Next, we establish that every cycle in a directed graph must contain at least
one back edge.
Corollary C.lO Let G = (N, A) be a directed graph, T a depth-first

spanning forest of G and rPostorder the associated ordering computed by the
algorithm of Table C.l. Any cycle of G contains at least one back edge. •
Proof A cycle is a path [no, · · ·, nm] with no = nm and m ~ 1. Then, since

rPostorder[no] = rPostorder[nm], we must have rPostorder[n;] ~ rPostorder[ni+l] for
some O ~ i < m. Thus Lemma C.9 applies. •
The ordering rPostorder topologically sorts the depth-first spanning forest.
Corollary C.ll Let G = (N, A) be a directed graph, T a depth-first

spanning forest of G and rPostorder the associated ordering computed by the
algorithm of Table C.l. Then rPostorder topologically sorts T as well as the
forward and cross edges. •
Proof By Lemma C.9, for any edge (n, n'), rPostorder[n] < rPostorder[n'] if and
only if the edge is not a back edge, that is, if and only if the edge is a tree edge in
T or a forward edge or a cross edge. Thus rPostorder topologically sorts T as well
as the forward and cross edges. •
Loop connectedness. Let G = (N, A) bea directed graph with handle
H. The loop connectedness parameter of G with respect to a depth-first
spanning forest T constructed by the algorithm of Table C.l, is the largest
number of back edges found in any cycle-free path of G; we write d(G, T),
or d( G) when T is clear from the context, to denote the loop connectedness
parameter of a graph. The value of d(G) for the graph in Figure C.l is 1.
Let a dominator-back edge be an edge (n1, n2) where the target n2 dominates
the source n1. A dominator-back edge (n1, n2) is a back edge regardless of
the choice of spanning forest T because the path from H to n1 in T must
contain n2 (given that n2 dominates n1). The graph shown in Figure C.3
shows that there may be more back edges than there are dominator-back
edges; indeed, it has root r and no dominator-back edges, but any spanning
forest T will characterise one of the edges between n1 and n2 as a back edge.
The literature contains many definitions of the concept of reducible graph.
We shall say that a directed graph G = (N, A) with handle H is reducible
Co2 Reverse Postorder 425
Figure C.3: An irreducible grapho
if and only if the graph (N, A\ Adb) obtained by removing the set Adb of
dominator-back edges is acyclic and stiH has H as handleo The simplest
example of an irreducible graph is shown in Figure Co3o
Reducible graphs are of interest because for a reducible graph G with handle
Hand an arbitrary depth-first spanning forest T, it will be the case (as shown
below) that an edge is characterised as a back edge with respect to T if and
only if it is a dominator-back edgeo It follows that the loop connectedness
parameter is then independent of the choice of depth-first spanning foresto
Lemma C.12 Let G = (N, A) be a reducible graph with handle H, T

a depth first spanning forest for G and H, and rPostorder the associated
ordering computed by the algorithm of Table Col. Then an edge is a back
edge if and only if it is a dominator-back edgeo •
Proof We already argued that a dominator-back edge necessarily is a back edge
with respect to To Next suppose by way of contradiction that there is a back edge
(n,, nt) that is not a dominator-back edgeo It is clear that the tree edges (i.eo the
edges in T) are not back edges and hence not dominator-back edges and therefore
they all occur in the graph (N, A\ Adb) constructed aboveo Next let T' be the
graph obtained by adding the edge (n,, nt) to T o Then also all edges in T' occur
in the graph (N, A \ Adb) o The path in T' from nt to n,, followed by the back edge
(n,, nt), constitutes a cycle in T' and hence in (N, A\ Adb)o This contradicts the
acyclicity of (N, A\ Adb) and hence the reducibility of Go •
Example C.13 Once more let S bea uniquely labelled statement from
WHILE and consider the fiow graph (labels(S),flow(S)) with root init(S)o It
is reducible: Each while loop can be entered only at the test node which then
dominates all the nodes for the body of the loop and hence all the back edges
introduced by the while loop are also dominator-back edgeso Clearly the
graph consisting of tree edges, forward edges and cross edges will be acyclico
The loop connectedness parameter equals the maximum number of back edges
(and hence dominator-back edges) of a cycle-free path in the fl.ow graph; it
follows that it is equal to the maximum number of nested while loops in the
program. •
Another interesting property of rPostorder for reducible graphs is the following
result.
Corollary C.14 Let G = (N, A) be a reducible graph with handle H.

Any cycle-free path inG beginning with a node in the handle, is monoton-
ically increasing by the ordering rPostorder computed by the algorithm of
Table C.l. •
Proof Any such path must contain no dominator-back edges and thus by Lemma
C.l2 is either a path in the depth-first spanning forest or a sequence of paths
from the forest connected by forward or cross edges. The result then follows from
Corollary C.ll. •
Other orders. As we have seen, reverse postorder numbers the nodes

in the reverse of the order in which they were last visited in the construction
of the depth-first spanning forest. Two commonly used alternative orderings
on nodes are preorder and breadth-first order; as an example, the preorder
for the tree in Figure C.2 is b1,b2,S2,S1,b3,S3 and the breadth-first order is
b1, b2, b3, S2, S1, S3. Like reverse postorder, both orders topologically sort the
depth-first spanning forest. They also topologically sort forward edges but
they do not necessarily topologically sort cross edges. (For preorder, consider
the edge from b3 to S1 in the example; for breadth-first order, modify the
example to have an additional node between b1 and b3 .) This observation
makes reverse postorder the better choice for a number of iterative algorithms.
C.3 Regular Expressions

An alphabet is a finite and non-empty set E of symbols; we shall assume
that it is disjoint from the set {A, 0, (, ), +,·,*}of special symbols. A regular
expression over E is any expression constructed by the following inductive
definition:
1. A and 0 are (so-called atomic) regular expressions. For any a E E, a is

a (so-called atomic) regular expression.
2. If R1 and R2 are regular expressions then (R1 + R2), (R1 · R2) and
(R1 )* are (so-called compound) regular expressions.
The above definition constructs expressions that are fully parenthesised; by

placing a precedence on the operators so that '*' binds more tightly than '·',
and '·' binds more tightly than '+', most parentheses can be omitted.
A string w EE* is a sequence of symbols from E. A language L over E is a

set of strings, i.e. L ~ E*. The language defined by a regular expression R is
.C[R] defined by:
.C[A] {A}
.C[0] 0
.C[a] = {a} for all a E E
.C[R1 + R2] .C[R1] U .C[R2]
.C[R1 · R2] .C[Rd · .C[R2]
.C[R~] u 00
k=O
(.C[Rl])k
where L1 · L2 = {w1w2 1 w1 E L1 and w2 E L2}, L 0 ={A} and Li+ 1 =Li· L.

Two regular expressions R1 and R2 are equivalent, denoted R1 = R2, if their
languages are equal, that is .C[Rd = .C[R2].
A homomorphism from Ei to E2 is a function h : E1 --+ E2 that is extended
to operate on words h(a1 ···am)= h(a1) · · · h(am) and on languages h(L) =
{h(w) 1 w EL}. It may be extended to operate on regular expressions:
h(0) = 0
h(A) A
{ ~· ... ·bm if h(a) = b1 · · · bm 1\ m >O

h(a)
if h(a) =A
h(R1 + R2) h(Rl) + h(R2)
h(R1 · R2) h(R1) · h(R2)
h(R*) h(R)*
If Ris a regular expression over E 1 then it is immediate that h(R) is a regular

expression over E2 and that .C(h(R)) = h(.C(R)).
Concluding Remarks
There are a number of good books on graph theoretic concepts; aur presen-
tation is based on [48], Chapter 5 of [4], Chapters 3 and 4 of [69], Chapter
10 of [5] and Chapter 7 of [110]. For more information on regular languages
consult a text book such as [76].
Index of N otation
-- 214, 219 220
341
fl [VJ, 246
r , 22, 285
- r re: T , 22
-fin VIII
17, 1 • 20 r 1 x , 286
$ ' 324 329, 347 f r e : r & lţ), 24
1= • 309 r, 24 287, 307, 321
'V 226 ")', 15
1 154 2 6 "Y" 237
( 1 ' 367 L, 69
• 62
!;;;; • 29 34
tb 66 69
L. , 16
;;;;) • 367
î 96 , 91, 99 100
~ • 29 A, 344
2 • 30 ~ VIII
r : • 22 t/J~A , 116
r : & ' 24 lţ), 24 287 306, 321 327 335, 343
r '"'-+ • 211 , 219
lţ) !;;;; cp' ' 348
r
-
27, 212 219
r lţ) 1 !;;;; '-P2' 29
' 154
IPI ~ '{)2, 29
' 86
1T , 284
"" 367
p, 86, 153, 333
O' 15, 300 306 p r . (S , c;) - (S' <;'), 86
a" , 237 p r . {S, c;) - ' 6
{J, 216 306 p 1 X 154
fJ 2 cp, 30 p 11 , 144, 187 191
{J, - !32. 220 p. 86
fJR, 217 (! , 331
{J" 237 lY 332
ll. 91 , 96, 97 99, 100, 191 230 E , 17
6 91 , 191 (1 , 54, 105
[6 t] 96 C1J ""V C12 62

r6,l"Jk, 9 193 (i 327 335 343
61 7 ' 86, 244 320 333
f], 237 c;[M ) 244
430 Index of Notation
246
<;.,/> c, 11, 144, 187, 193
T, 285, 300 c*, 174
r ~ T', 324, 329, 347 c, 142, 284
1'1 G ~' 298 C~e, 144, 187, 193
7', 24,287,306,321,327,335,343 ce, 191
(), 301 CEnv, 191
()A F C, 309 ch, 339
~' 86, 105, 320 Chan, 339
(, 327 clear, 52
close-construct, 153
A, 55, 108 Const, 142, 284
Acp, 73 CP, 102
a, 3 CP, 342
AEentry, 40 cs, 14
AEexit, 40 cycles, 418
AExp*' 39 .Q*, 82
AExp, 3
~' 187
AExp(·), 39 d, 187
AHeap, 111, 114 de, 182
ALoc, 110
d 0 p, 183
ALoc(H), 111
Data, 182
ALoc(S), 111
Analysis=, 69
D--;-~ 187
Analysis!;;;, 69 DCache, 187
Analysis, 369 def, 52
Analysis, 65 DEnv, 187
AnncA, 343 DOM, 13
Ann, 287 doin, 86, 154, 286, 301
AnnEs, 327 DU, 54
AnnRI, 335 du, 53
AnnsE, 321 E, 69, 341
AState, 110, 114 e1 ---+ e2, 341
AType, 300 e, 142, 283, 339
AV, 101, 317 ee, 331
AVar, 306 EExp, 331
B, 55, 108 empty, 368
b, 3 Env, 86, 153, 333
BExp, 3 ~' 144, 187, 191
BExp(·), 39 EVal, 333
bind-construct, 87, 154 Exp, 142, 283, 339
[B]t, 37 Ext, 223, 402
Blocks*, 38 extract, 368
blocks*, 84 :F, 68
blocks, 36, 83 J, 91
c, 308 :Fcp, 73
Index of Notation 431
[_fl~, 230 killAE, 40

IL 93, 96, 98, 1oo, 101 killLv, 49
killRo, 43
Il c ' 93, 96, 98, 100, 101
c, r killvB, 46
J;, 91 killx, 117
r;;_, 92 's!.llx.sel, 125
fcx l 92 L, 91
fv, 226 1!, 3, 142
J[A, 115, 116 l~, 225
f., 186 Lab*, 38, 171
h, 68 Lab, 3, 142
/p, 212, 219 labels*, 84
jCP 73 labels, 37, 83
c '
final*, 84 lfp~, 230
final, 36, 83 lfp'V, 227
Fix, 223, 402 lfp, 223, 402
flow*, 84 Loc, 86, 105, 320
flow, 37, 83 Lv=, 60
flo~, 38 LV<:::, 60
FV, 143, 367 LVentry, 50
genAE' 40 LVexit, 50
genLv, 50 MFP, 74
genR 0 , 43 MOP, 79
geny 8 , 46 MVP, 90
gfp, 223, 402 N, 55
H, 111, 114 nx, 110
H, 106 n0, 110
Heap, 106 n,3
IAV, 101 Num,3
id, 68, 302 o, 333
ie, 154 Observe, 338
IExp, 154 Offset, 333
inf, 222 Op, 142, 284
infl, 369 op, 182
init*, 84 op, 142, 284
init, 36, 83 opa, 55, 73
insert, 368 apa, 4
inter-flow*, 84 opb, 55
Interval, 221 opb, 4
is, 112, 114 opr, 55
IsShared, 114 opr, 4
it, 154 P*, 82
ITerm, 154 p, 107
JUDGcFA[r f-uL e: T], 299 p f- h 1> [2, 212, 219
432 Index of Notation
p f- VI -vt V2, 211, 219 Stmt, 3

Parity, 244 Store, 86,320,333
path, 79 SType, 306
Pnt, 284 sup, 222
PP, 342 SVal, 333
Proc, 342 [t~'I/J, 367
R- R, 214 t, 142, 367
R1- R2, 219 T~v, 285
Rf3, 217 TEnv, 287
R, 214 Term*, 171
R, 158 Term, 142
f, 332 tr, 13
r, 331, 343 Trace, 13
ran, 86 TrVar~, 134
Range, 248 TVar, 300, 306
RD f- S 1> S', 27 Type, 285
RD, 5 TypecA, 343
RDentry, 43 TypeES' 327
RDexit, 43 TypeR1, 335
Red, 223,402 Type5 E, 321
RegcA, 343 ~e[T], 298
RegR 1, 331 Type, 287
rn, 331 UcFA, 307
RName, 331 UuL, 302, 305
rPostorder, 375 UD, 54
RVar, 331 ud, 53
S: RD1 ~ RD2, 18 use, 52
S: E :0~ E, 20 V, 159
S: E ~ E, 17 v, 144, 182, 187, 191
s*, 38 v, 153, 293, 333, 341
s, 3 Val, 153, 293, 341
s, 110, 114 §!d, 182
s, 367 Val, 144, 187, 191
SAnn, 306 Var*, 38, 171
SchemecA, 343 Var, 3, 142, 284
SchemeR1, 335 VBentry, 47
Sel, 104 VBexit, 47
sel, 104 vpath, 90
SG,114 WcFA, 309
Shape, 115 w, 74
Sign, 238 WuL, 301
SRD, 13 w, 333
State, 54, 105 (xi ;:;! ti)~ 1 , 367
Statecp, 72
Index
abstract 0-CFA, 147 Available Expressions Analysis, 39

abstract cache, 144, 193
abstract data value, 182 back edge, 422
abstract environment, 144, 191 backward analysis, 66, 85
abstract heap, 111 BANE, 387
Abstract Interpretation, 13, 211 base of origin, 356
abstraction function, 15, 234 basic block, 136
abstract location, 109, 110 behaviour, 344
abstract reachability component, 202 behaviour variable, 344
abstract state, 110 binding time analysis, 356
abstract summary location, 110 Bit Vector Framework, 137, 380,
abstract syntax, 4, 142 387
abstract value, 144, 191
abstract worklist algorithm, 369 call-by-name, 207
acceptable 0-CFA, 146 call-by-result, 82
acyclic, 418 call-by-value, 82
additive, 395 Call-Tracking Analysis, 23
adjoint, 239 called procedure, 102
adjunction, 16, 236 call string, 96, 196
affine, 396 cartesian product, 398
alphabet, 426 Cartesian Product Algorithm, 196
ancestor, 420 chain, 399
annotated type, 287, 321, 327, 335 channel, 339
annotated type environment, 287 channel identifier, 339
Annotated Type System, 18, 283 channel pool, 342
annotation, 287, 321, 327, 335 Chaotic Iteration, 25
annotation substitution, 309 child, 420
annotation variable, 306 closure, 153
arc, 417 Closure Analysis, 199
Array Bound Analysis, 221, 247 Code Motion, 54
ascending chain, 399 coinductive definition, 150, 165, 412
Ascending Chain Condition, 67,399 collecting semantics, 13, 266, 277
assigned variable, 101 combination operator, 67
assumption set, 99, 198 Communication Analysis, 339, 343
atomic subtyping, 350 compatible shape graph, 114
augmented type, 300 complete lattice, 393
434 Index
completely additive, 395 Descending Chain Condition, 68,

completely multiplicative, 396 399
complete path, 89 Detection of Signs Analysis, 91, 183
concrete syntax, 4 DFSF, 422
concretisation function, 15, 234 DFST, 422
conditiona! constraint, 12, 173, 367 digraph, 417
conservative extension, 291 directed graph, 375, 417
Constant Folding, 27, 72, 132 directed path, 417
Constant Propagation Analysis, 72, directly dominates, 421
132, 186, 212, 265, 266 direct product, 254
constraint, 173, 308 direct tensor product, 255
constraint based 0-CFA, 174 distributive, 69, 395
Constraint Based Analysis, 141 Distributive Framework, 69
constraint based approach, 8, 10, dominates, 420
11 dominator, 420
constraint system, 60, 69, 367 d'Ur-chain, 52, 132
context-insensitive, 95, 150, 190 duality, 273
context-sensitive, 95, 190 dynamic dispatch problem, 84, 142
context environment, 191
context information, 91, 191 edge, 417
contravariant, 324 edge array, 179
Control Flow Analysis, 10, 213, 287, effect, 24, 321, 327, 335
288 Effect System, 18
correctness relation, 62, 158, 214, elementary block, 3, 36
241, 260 embellished Monotone Framework,
91
course of values induction, 407
environment, 86, 153, 332
covariant, 324
equality of annotations, 290
cover, 301, 309
equational approach, 5
CPA, 196
equation system, 60, 65, 66, 69,
cross edge, 422
366
cycle, 418
equivalent, 427
evaluation context, 341
DAG, 418 eventually stabilises, 399
data array, 179 Exception Analysis, 325
Data Flow Analysis, 5, 35 expression, 142, 283, 339
Dead Code Elimination, 49, 53, 132 extended expression, 331
Definition-Use chain, 52 extended type, 335
definition clear path, 52 extensive, 223, 402
Denotational Semantics, 223, 273 extraction function, 237, 246
depth-first spanning forest, 375, 422 extremallabel, 69
depth-first spanning tree, 422 extremal value, 69, 186
derivation sequence, 57
descendant, 420 faint variable, 136
descending chain, 399 fast, 391
Index 435
fastness closure, 391 induced analysis, 16, 258

FIFO, 374 induction on the shape, 406
finallabel, 36 inductive definition, 165, 408
finite chain, 399 inequation system, 366
first-in first-out, 374 infl.uence set, 369
first-order analysis, 212 initial labei, 36
fixed point, 223, 402 injective, 395
fl.ow, 37, 69 instance, 69, 186, 262
fl.ow-insensitive, 101, 150 instantiation, 329, 338
fl.ow-sensitive, 101 instrumented semantics, 133
fl.ow graph, 37 intermediate expression, 154
fl.ow variable, 365 intermediate term, 154
forest, 420 interprocedural analysis, 82, 196
forward analysis, 66, 85, 115 interprocedural fl.ow, 84, 142
forward edge, 422 intraprocedural analysis, 82
free algebra, 306 isolated entries, 39
free variable, 143 isolated exits, 39
fresh type variable, 302 isomorphism, 397
functional, 409
functional composition, 24 7 join semi-lattice, 67
Galois connection, 16, 234 k-CFA, 191, 198

Galois insertion, 242
generalisation, 329, 337 labei, 37
generalised Monotone Framework, labei consistent, 39
262 last-in first-out, 372
general subtyping, 350 latent effect, 24
generated by, 217 lazy, 207
graph, 417 least element, 394
graph formulation of the constraints, least fixed point, 223, 261, 402
177, 375 least upper bound, 393
greatest element, 394 LIFO, 372
greatest fixed point, 223, 402 live variable, 49
greatest lower bound, 393 Live Variables Analysis, 49
ground substitution, 301, 309 location, 86, 105, 320
ground validation, 309 logical relation, 214, 219
loop connectedness, 380, 424
handle, 375, 419 lower adjoint , 239
heap, 106 lower bound, 393
height, 399
hoisting, 46 materialise, 121
mathematical induction, 405
in-degree, 420 Maximal Fixed Point, 74
independent attribute analysis, 138, may analysis, 66, 115
249 Meet Over all Paths, 78
436 Index
Meet over all Valid Paths, 89 program point, 284

MFP solution, 74 proof by coinduction, 412
model intersection property, 162 proof by induction, 412
Modified Post Correspondence Prob- proof normalisation, 312, 362
lem, 79 proper, 420
monotone, 395 properly dominates, 421
Monotone Framework, 68, 391 property space, 67
monotone function space, 253, 398
monotone structure, 186, 275, 355 Reaching Definitions Analysis, 4,
Monotone Type System, 355 43
monovariant, 190 reduced graph, 381, 419
Moore family, 136, 162, 172, 215, reduced product, 256
299, 395 reduced tensor product, 256
MOP solution, 78 reducible, 424
multiple entry, 418 reduction operator, 244
multiplicative, 395 reductive, 223, 402
must analysis, 66, 115 reference variable, 319
MVP solution, 89, 90 region, 331, 333, 344
Region Inference, 330
narrowing operator, 230 region name, 331
Natural Semantics, 292 region polymorphic closure, 333
node, 417 region variable, 331
non-free algebra, 306 regular expression, 426
non-trivial expression, 39 relational analysis, 138, 250
representation function, 216, 237,
offset, 333 242, 260, 264
open system, 149, 182 reverse flow, 38
optimal analysis, 17, 261 reverse postorder, 375, 422
ordered forest, 420 root, 375, 419
ordered tree, 420 Round Robin Algorithm, 378
out-degree, 420
safe approximation, 168
PAG, 387 scaling factor, 356
parent, 420 second-order analysis, 212
partially ordered set, 393 security analysis, 356
partial ordering, 393 selector name, 104
path, 78, 417 self-loop, 417
pointer expression, 104 semantically reaching definitions,
polymorphic recursion, 336 13
polymorphism, 327, 329 semantic correctness, 295
polynomial k-CFA, 195, 198 semantics based, 3, 29
polyvariant, 190 semantics directed, 3, 29
procedure call graph, 102 sequential composition, 247
process, 339 Set Based Analysis, 198
process pool, 342 set constraints, 201, 387
Index 437
sets of states analysis, 265 tree edge, 422

Shape Analysis, 104, 274 type, 22, 285, 343
shape conformant subtyping, 324, Type and Effect System, 17, 283
350 type environment, 22, 285
shape graph, 109, 114 type reconstruction, 301, 309
sharing information, 112 type schema, 327, 335, 344
Sharlit, 387 type substitution, 308
Side Effect Analysis, 320 type variable, 300, 306
simple annotation, 306 typing judgement, 286, 288, 321,
simple substitution, 307 329, 336, 345
simple type, 306
simple type environment, 307 UCAl, 291, 306
smash product, 398 ud-chain, 52, 132, 145
Spare, 387 underlying type, 287
state, 54, 105 underlying type system, 284
storable value, 333 unification procedure, 302, 305, 307
store, 86, 320, 333 uniform k-CFA, 191, 193, 198
strict, 396 unit, 356
strong component, 381, 419 upper adjoint, 239
strongly connected, 381, 419 upper bound, 393
structural induction, 406 upper bound operator, 225
Structural Operational Semantics, upper closure operator, 270
54, 153 Use-Definition chain, 52, 145
subeffecting, 288, 324, 329, 336,
347 valid path, 89
subject reduction result, 158 value, 153, 293, 341
substitution, 301 vertex, 417
subsumption rule, 19, 21 Very Busy Expressions Analysis,
subtyping, 324, 329, 336, 347 46
surjective, 395
well-founded induction, 407
syntactic completeness, 308, 314
well-founded ordering, 407
syntactic soundness, 308, 312
widening operator, 226, 267, 391
syntax directed 0-CFA, 169
worklist, 74, 179, 368, 369
System Z, 387
Y2K, 356
Tarski's Fixed Point Theorem, 402
temporal order, 339
tensor product, 252, 271
term, 142
topologica! sort, 418
total function space, 252, 398
trace, 13, 133
transfer function, 68
transition, 55
tree, 420
Bibliography
[1] M. Abadi, A. Banerjee, N. Heintze, and J. G. Riecke. A core calculus

of dependency. In Proc. POPL '99, pages 147-160. ACM Press, 1999.
[2] O. Agesen. The cartesian product algorithm. In Proc. ECOOP'95,

volume 952 of Lecture Notes in Computer Science, pages 2-26. Springer,
1995.
[3] O. Agesen, J. Palsberg, and M. Schwartzbach. Type inference of

SELF: Analysis of objects with dynamic and multiple inheritance. In
Proc. ECOOP'93, volume 707 of Lecture Notes in Computer Science.
Springer, 1993.
[4] A. V. Aho, J. E. Hopcroft, and J. D. Ullman. The Design and Analysis

of Computer Algorithms. Addison Wesley, 1974.
[5] A. V. Aho, R. Sethi, and J. D. Ullman. Compilers: Principles, Tech-

niques, and Tools. Addison Wesley, 1986.
[6] A. Aiken. Set constraints: Results, applications and future directions.

In Proc. Second W orkshop on the Principles and Practice of Constraint
Programming, volume 874 of Lecture Notes in Computer Science, pages
326-335. Springer, 1994.
[7] A. Aiken. Introduction to set constraint-based program analysis. Sci-

ence of Computer Programming, 35(2):79-111, 1999.
[8] A. Aiken, M. Făhndrich, J. S. Foster, and Z. Su. A toolkit for con-

structing type- and constraint-based program analyses. In Proc. Types
in Compilation, volume 1473 of Lecture Notes in Computer Science,
pages 78-96. Springer, 1998.
[9] A. Aiken and E. Wimmers. Type inclusion constraints and type infer-
ence. In Proc. FPCA '93, pages 31-41. ACM Press, 1993.
[10] A. Aiken, E. Wimmers, and T.K. Lakshman. Soft typing with condi-
tiona! types. In Proc. POPL '94, pages 163-173. ACM Press, 1994.
440 Bibliography
[11] F. E. Allen and J. A. Cocke. A program data flow analysis procedure.

Communications of the ACM, 19(3):137-147, 1976.
[12] B. Alpern, M. M. Wegman, and F. K. Zadeck. Detecting equality of
variables in programs. In Proc. POPL '88, pages 1-11. ACM Press,
1988.
[13] T. Amtoft, F. Nielson, and H. R. Nielson. Type and Effect Systems:

Behaviours for Concurrency. Imperial College Press, 1999.
[14] T. Amtoft, F. Nielson, and H.R. Nielson. Type and behaviour recon-
struction for higher-order concurrent programs. Journal of Functional
Programming, 7(3):321-347, 1997.
[15] T. Amtoft, F. Nielson, H.R. Nielson, and J. Ammann. Polymorphic

subtyping for effect analysis: The dynamic semantics. In Analysis and
Verification of Multiple-Agent Languages, volume 1192 of Lecture Notes
in Computer Science, pages 172-206. Springer, 1997.
[16] A. Arnold and I. Guessarian. Mathematics for Computer Science. Pren-

tice Hall International, 1996.
[17] U. Assmann. How to uniformly specify program analysis and transfor-

mation. In Proc. CC '96, volume 1060 of Lecture Notes in Computer
Science, pages 121-135. Springer, 1996.
[18] A. Banerjee. A modular, polyvariant, and type-based closure analysis.

In Proc. ICFP '97, pages 1-10. ACM Press, 1997.
[19] P. N. Benton. Strictness logic and polymorphic invariance. In Proc. Sec-
ond International Symposium on Logical Foundations of Computer Sci-
ence, volume 620 of Lecture Notes in Computer Science, pages 33-44.
Springer, 1992.
[20] P. N. Benton. Strictness properties of lazy algebraic datatypes. In
Proc. WSA '93, volume 724 of Lecture Notes in Computer Science,
[21] S. K. Biswas. A demand-driven set-based analysis. In Proc. POPL '97,

pages 372-385. ACM Press, 1997.
[22] C. Bodei, P. Degano, F. Nielson, and H. R. Nielson. Control flow
analysis for the 1r-calculus. In Proc. CONCUR '98, number 1466 in
Lecture Notes in Computer Science, pages 84-98. Springer, 1998.
[23] C. Bodei, P. Degano, F. Nielson, and H. R. Nielson. Static analysis of
processes for no read-up and no write-down. In Proc. FOSSACS'99,
number 1578 in Lecture Notes in Computer Science, pages 120-134.
Springer, 1999.
Bibliography 441
[24] F. Bourdoncle. Abstract interpretation by dynamic partitioning. Jour-

nal of Functional Programming, 10:407-435, 1992.
[25] F. Bourdoncle. Efficient chaotic iteration strategies with widenings. In

Proc. Formal Methods in Programming and Their Applications, volume
735 of Lecture Notes in Computer Science, pages 128-141. Springer,
1993.
[26] R. E. Bryant. Symbolic boolean manipulation with ordered binary

decision diagrams. Computing Surveys, 24(3), 1992.
[27] G. L. Burn, C. Hankin, and S. Abramsky. Strictness Analysis for

Higher-Order Functions. Science of Computer Programming, 7:249-
278, 1986.
[28] W. Charatonik and L. Pacholski. Set constraints with projections are

in NEXPTIME. In Proc. FOCS '94, pages 642-653, 1994.
[29] B. Le Charlier and P. Van Hentenryck. Experimental evaluation of a

generic abstract interpretation algorithm for prolog. ACM TOPLAS,
16(1 ):35-101, 1994.
[30] D. Chase, M. Wegman, and F. Zadeck. Analysis of pointers and struc-

tures. In Proc. PLDI '90, pages 296-310. ACM Press, 1990.
[31] C. Colby. Analyzing the communication topology of concurrent pro-

grams. In Proc. PEPM '95, pages 202-214. ACM Press, 1995.
[32] C. Colby. Determining storage properties of sequential and concurrent

programs with assignment and structured data. In Proc. SAS '95, vol-
ume 983 of Lecture Notes in Computer Science, pages 64-81. Springer,
1995.
[33] A. Cortesi, G. File, R. Giacobazzi, C. Palamidessi, and F. Ranzato.

Complementation in abstract interpretation. In Proc. SAS '95, Lecture
Notes in Computer Science, pages 100-117. Springer, 1995.
[34] A. Cortesi, G. File, R. Giacobazzi, C. Palamidessi, and F. Ranzato.

Complementation in abstract interpretation. ACM TOPLAS, 19(1):7-
47, 1997.
[35] P. Cousot. Semantics Foundation of Program Analysis. InS. S. Much-

nick and N. D. Jones, editors, Program Flow Analysis: Theory and
Applications, chapter 10, pages 303-342. Prentice Hall International,
1981.
[36] P. Cousot. Types as abstract interpretations. In Proc. POPL '97, pages

316-331. ACM Press, 1997.
442 Bibliography
[37] P. Cousot and R. Cousot. Abstract Interpretation: a Unified Lattice

Model for Static Analysis of Programs by Construction or Approxi-
mation of Fixpoints. In Proc. POPL '77, pages 238-252. ACM Press,
1977.
[38] P. Cousot and R. Cousot. Static determination of dynamic properties of

generalised type unions. In Conference on Language Design for Reliable
Software, volume 12(3) of ACM SIGPLAN Notices, pages 77-94, 1977.
[39] P. Cousot and R. Cousot. Systematic Design of Program Analysis
Frameworks. In Proc. POPL '79, pages 269-282, 1979.
[40] P. Cousot and R. Cousot. Comparing the Galois Connection and

Widening/Narrowing Approaches to Abstract Interpretation. In
Proc. PLILP '92, volume 631 of Lecture Notes in Computer Science,
[41] P. Cousot and N. Halbwachs. Automatic Discovery of Linear Restraints

Among Variables of a Program. In Proc. POPL '78, pages 84-97. ACM
Press, 1978.
[42] R. Cytron, J. Ferrante, B. K. Rosen, M. N. Wegman, and F. K. Zadek.

Efficiently computing static single assignment form and the control
dependence graph. ACM TOPLAS, 13(4):451-490, 1991.
[43] B. A. Davey and H. A. Priestley. Introduction to Lattices and Or-

der. Cambridge Mathematical Textbooks. Cambridge University Press,
1990.
[44] A. Deutsch. On Determining Lifetime and Aliasing of Dynamically Al-

located Data in Higher Order Functional Specifications. In Proc. POPL
'90, pages 157-169. ACM Press, 1990.
[45] A. Deutsch. Interprocedural may-alias analysis for pointers: Beyond
k-limiting. In Proc. PLDI '94, pages 230-241. ACM Press, 1994.
[46] P. H. Eidorf, F. Henglein, C. Mossin, H. Niss, M. H. S0rensen, and

M. Tofte. AnnoDomini: From type theory to year 2000 conversion
tool. In Proc. POPL '99, pages 1-14. ACM Press, 1999.
[47] M. Emami, R. Ghiya, and L. J. Hendren. Context-sensitive inter-

procedural points-to analysis in the presence of function pointers. In
Proc. PLDI '94, pages 242-256. ACM Press, 1994.
[48] S. Even. Graph Algorithms. Pitman, 1979.
[49] K.-F. Faxen. Optimizing lazy functional programs using flow inference.
In Proc. SAS '95, volume 983 of Lecture Notes in Computer Science,
Bibliography 443
[50] K.-F. Faxen. Polyvariance, polymorphism, and flow analysis. In

Proc. Analysis and Verijication of Multiple-Agent Languages, volume
1997.
[51] C. Fecht and H. Seidl. An even faster solver for general systems of
equations. In Proc. SAS '96, volume 1145 of Lecture Notes in Computer
[52] C. Fecht and H. Seidl. Propagating differences: An efficient new fix-

point algorithm for distributive constraint systems. In Proc. ESOP
'98, volume 1381 of Lecture Notes in Computer Science, pages 90-104.
Springer, 1998.
[53] C. Fecht and H. Seidl. Propagating differences: An efficient new fix-

point algorithm for distributive constraint systems. Nordic Journal of
Computing, 5:304-329, 1998.
[54] C. Fecht and H. Seidl. A faster solver for general systems of equations.
Science of Computer Programming, 35(2):137-161, 1999.
[55] C. N. Fischer and Jr. R. J. LeBlanc. Crafting a Compiler. Ben-

jamin/Cummings, 1988.
[56] C. Flanagan and M. Felleisen. Well-founded touch optimizations for fu-

tures. Technical Report Rice COMP TR94-239, Rice University, 1994.
[57] C. Flanagan and M. Felleisen. The semantics of future and its use in
program optimization. In Proc. POPL '95, pages 209-220. ACM Press,
1995.
[58] Y.-C. FUh and P. Mishra. Polymorphic subtype inference: Closing the
theory-practice gap. In Proc. TAPSOFT '89, volume 352 of Lecture
[59] Y.-C. FUh and P. Mishra. Type inference with subtypes. Theoretical
Computer Science, 73:155-175, 1990.
[60] K. L. S. Gasser, F. Nielson, and H. R. Nielson. Systematic realisation of

control flow analyses for CML. In Proc. ICFP '97, pages 38-51. ACM
Press, 1997.
[61] R. Ghiya and L. Hendren. Connection analysis: a practica! interproce-

dural analysis for C. In Proc. of the eight workshop on languages and
compilers for parallel computing, 1995.
[62] R. Ghiya and L. J. Hendren. Is it a tree, a dag, or a cyclic graph?

a shape analysis for heap-directed pointers in C. In G. Kahn, editor,
Proc. POPL '96, pages 1-15. ACM Press, 1996.
444 Bibliography
[63) R. Giacobazzi and F. Ranzato. Compositional optimization of dis-

junctive abstract interpretations. In Proc. ESOP '96, volume 1058 of
[64) R. Giacobazzi and F. Ranzato. Optimal domains for disjunctive ab-
stract interpretation. Science of Computer Programming, 32:177-210,
1998.
[65) R. Giegerich, U. Moncke, and R. Wilhelm. Invariance of approximative

semantics with respect to program transformations. In Proc. GI -
11. Jahrestagung, volume 50 of Informatik Fachberichte, pages 1-10.
Springer, 1981.
[66) P. Granger. Static analysis of arithmetical congruences. International
Journal of Computer Mathematics, 30:165-190, 1989.
[67) P. Granger. Static Analysis of Linear Congruence Equalities among
Variables of a Program. In Proc. TAPSOFT '91, volume 493 of Lecture
[68) R. R. Hansen, J. G. Jensen, F. Nielson, and H. R. Nielson. Abstract
interpretation of mobile ambients. In Proc. SAS '99, Lecture Notes in
Computer Science. Springer, 1999.
[69) M. S. Hecht. Flow Analysis of Computer Programs. North Holland,
1977.
[70) N. Heintze. Set-based analysis of ML programs. In Proc. LFP '94,
pages 306-317, 1994.
[71) N. Heintze. Control-fiow analysis and type systems. In Proc. SAS
Springer, 1995.
[72) N. Heintze and J. Jaffar. A decision procedure for a class of Herbrand
set constraints. In Proc. LICS '90, pages 42-51, 1990.
[73) N. Heintze and J. Jaffar. An engine for logic program analysis. In
Proc. LICS '92, pages 318-328, 1992.
[74) Nevin Heintze and Jon G. Riecke. The SLam calculus: Programming
with Secrecy and Integrity. In Proc. POPL '98, pages 365-377. ACM
Press, 1998.
[75) F. Henglein and C. Mossin. Polymorphic binding-time analysis. In
Proc. ESOP '94, volume 788 of Lecture Notes in Computer Science,
[76] J. E. Hopcroft and J. D. Ullman. Introduction to Automata Theory,
Languages and Computation. Addison Wesley, 1979.
Bibliography 445
[77] S. Horwitz, A. Demers, and T. Teitelbaum. An efficient general iterative

algorithm for datafiow analysis. Acta Informatica, 24:679-694, 1987.
[78] S. Jagannathan and S. Weeks. Analyzing Stores and References in a
Parallel Symbolic Language. In Proc. LFP '94, pages 294-305, 1994.
[79] S. Jagannathan and S. Weeks. A unified treatment of fiow analysis in
higher-order languages. In Proc. POPL '95. ACM Press, 1995.
[80] S. Jagannathan and A. Wright. Effective fiow analysis for avoiding
run-time checks. In Proc. SAS '95, volume 983 of Lecture Notes in
Computer Science, pages 207-224. Springer, 1995.
[81] T. P. Jensen. Strictness analysis in logical form. In Proc. FPCA
Springer, 1991.
[82] T. P. Jensen. Disjunctive strictness analysis. In Proc. LICS '92, pages
174-185, 1992.
[83] M. P. Jones. A theory of qualified types. In Proc. ESOP '92, volume

1992.
[84] N. D. Jones and S. S. Muchnick. Flow analysis and optimization ofLisp-

like structures. In S. S. Muchnick and N. D. Jones, editors, Program
Flow Analysis: Theory and Applications, chapter 4, pages 102-131.
Prentice Hall International, 1981.
[85] N. D. Jones and S. S. Muchnick. A fiexible approach to interprocedural
data fiow analysis and programs with recursive data structures. In
[86] N. D. Jones and F. Nielson. Abstract Interpretation: a Semantics-
Based Tool for Program Analysis. In Handbook of Logic in Computer
Science volume 4. Oxford University Press, 1995.
[87] M. Jourdan and D. Parigot. Techniques for improving grammar fiow
analysis. In Proc. ESOP '90, volume 432 of Lecture Notes in Computer
[88] P. Jouvelot. Semantic Parallelization: a practica! exercise in abstract
interpretation. In Proc. POPL '87, pages 39-48, 1987.
[89] P. Jouvelot and D. K. Gifford. Reasoning about continuations with
control effects. In Proc. PLDI '89, ACM SIGPLAN Notices, pages
218-226. ACM Press, 1989.
[90] P. Jouvelot and D. K. Gifford. Algebraic reconstruction of types and

effects. In Proc. POPL '91, pages 303-310. ACM Press, 1990.
446 Bibliography
[91] G. Kahn. Natural semantics. In Proc. STACS'87, volume 247 of Lecture

[92] J. B. Kam and J. D. Ullman. Global data fiow analysis and iterative
algorithms. Journal of the ACM, 23:158-171, 1976.
[93] J. B. Kam and J. D. Ullman. Monotone data fiow analysis frameworks.

Acta Informatica, 7:305-317, 1977.
[94] M. Karr. Affine Relationships among Variables of a Program. Acta

Informatica, 6(2):133-151, 1976.
[95] A. Kennedy. Dimension types. In Proc. ESOP '94, volume 788 of

[96] G. Kildall. A Unified Approach to Global Program Optimization. In

[97] M. Klein, J. Knoop, D. Koschiitzki, and B. Steffen. DFA & OPT-

METAFrame: A toolkit for program analysis and optimisation. In
Proc. TACAS '96, volume 1055 of Lecture Notes in Computer Science,
[98] D. E. Knuth. An empirica! study of Fortran programs. Software -

Practice and Experience, 1:105-133, 1971.
[99] W. Landi and B. G. Ryder. Pointer-Induced Aliasing: A Problem

Classification. In Proc. POPL '91, pages 93-103. ACM Press, 1991.
[100] W. Landi and B. G. Ryder. A safe approximate algorithm for inter-

procedural pointer aliasing. In Proc. PLDI '92, pages 235-248. ACM
Press, 1992.
[101] J. Larus and P. Hilfinger. Detecting confiicts between structure ac-

cesses. In Proc. PLDI '88, pages 21-34. ACM Press, 1988.
[102] J. M. Lucassen and D. K. Gifford. Polymorphic effect analysis. In

[103] T. J. Marlowe and B. G. Ryder. Properties of data fiow frameworks-

a unified model. Acta Informatica, 28(2):121-163, 1990.
[104] F. Martin. Pag- an efficient program analyzer generator. Journal of

Software Tools for Technology Transfer, 2(1):46-67, 1998.
[105] F. Masdupuy. Using Abstract Interpretation to Detect Array Data

Dependencies. In Proc. International Symposium on Supercomputing,
pages 19-27, 1991.
Bibliography 447
[106] R. Milner. Communication and Concurrency. Prentice Hall Interna-

tional, 1989.
[107] J. Mitchell. Type inference with simple subtypes. Joumal of Functional
Programming, 1(3):245-285, 1991.
[108] B. Monsuez. Polymorphic types and widening operators. In Proc. Static
Analysis (WSA '93}, volume 724 of Lecture Notes in Computer Science,
[109] R. Morgan. Building an Optimising Compiler. Digital Press, 1998.
[110] S. Muchnick. Advanced Compiler Design and Implementation. Morgan

Kaufmann Publishers, 1997 (third printing).
[111] F. Nielson. Abstract Interpretation using Domain Theory. PhD thesis,
University of Edinburgh, Scotland, 1984.
[112] F. Nielson. Program Transformations in a denotational setting. ACM
TOPLAS, 7:359-379, 1985.
[113] F. Nielson. Tensor Products Generalize the Relational Data Flow Anal-
ysis Method. In Proc. 4th Hungarian Computer Science Conference,
pages 211-225, 1985.
[114] F. Nielson. A formal type system for comparing partial evaluators.
In D. Bj0rner, A. P. Ershov, and N. D. Jones, editors, Proc. Partial
Evaluation and Mixed Computation, pages 349-384. North Holland,
1988.
[115] F. Nielson. Two-Level Semantics and Abstract Interpretation. Theo-

retical Computer Science -Fundamental Studies, 69:117-242, 1989.
[116] F. Nielson. The typed >.-calculus with first-class processes. In
Proc. PARLE'89, volume 366 of Lecture Notes in Computer Science,
[117] F. Nielson. Semantics-directed program analysis: a tool-maker's per-
spective. In Proc. Static Analysis Symposium (SAS), number 1145 in
[118] F. Nielson and H. R. Nielson. Finiteness Conditions for Fixed Point
Iteration. In Proc. LFP '92, pages 96-108. ACM Press, 1992.
[119] F. Nielson and H. R. Nielson. From CML to process algebras. In Proc.
CONCUR '93, volume 715 of Lecture Notes in Computer Science, pages
493-508. Springer, 1993.
[120] F. Nielson and H. R. Nielson. From CML to its process algebra. The-
oretical Computer Science, 155:179-219, 1996.
448 Bibliography
[121] F. Nielson and H. R. Nielson. Operational semantics of termination

types. Nordic Journal of Computing, pages 144-187, 1996.
[122] F. Nielson and H. R. Nielson. Infinitary Control Flow Analysis: a

Collecting Semantics for Closure Analysis. In Proc. POPL '97. ACM
Press, 1997.
[123] F. Nielson and H. R. Nielson. A prescriptive framework for designing

multi-levellambda-calculi. In Proc. PEPM'97, pages 193-202. ACM
Press, 1997.
[124] F. Nielson and H. R. Nielson. The flow logic of imperative objects. In

Proc. MFCS'98, number 1450 in Lecture Notes in Computer Science,
pages 22G-228. Springer, 1998.
[125] F. Nielson and H. R. Nielson. Flow logics and operational semantics.

Electronic Notes of Theoretical Computer Science, 10, 1998.
[126] F. Nielson and H. R. Nielson. Interprocedural control flow analysis. In

Proc. ESOP '99, number 1576 in Lecture Notes in Computer Science,
[127] F. Nielson, H.R. Nielson, and T. Amtoft. Polymorphic subtyping for

effect analysis: The algorithm. In Analysis and Verification of Multiple-
Agent Languages, volume 1192 of Lecture Notes in Computer Science,
[128] H. R. Nielson, T. Amtoft, and F. Nielson. Behaviour analysis and safety

conditions: a case study in CML. In Proc. FASE '98, number 1382 in
[129] H. R. Nielson and F. Nielson. Bounded fixed-point iteration. Journal

of Logic and Computation, 2(4):441-464, 1992.
[130] H. R. Nielson and F. Nielson. Semantics with Applications: A Formal

Introduction. Wiley, 1992. (An on-line version may be available at
http://www.imm.dtu.dk/~iis/Wiley_book/wiley.html).
[131] H. R. Nielson and F. Nielson. Higher-Order Concurrent Programs with

Finite Communication Topology. In Proc. POPL '94. Springer, 1994.
[132] H. R. Nielson and F. Nielson. Communication analysis for Concur-

rent ML. In F. Nielson, editor, ML with Concurrency, Monographs in
Computer Science, pages 185-235. Springer, 1997.
[133] H. R. Nielson and F. Nielson. Flow logics for constraint based analysis.
In Proc. CC '98, volume 1383 of Lecture Notes in Computer Science,
Bibliography 449
[134] H.R. Nielson, F. Nielson, and T. Amtoft. Polymorphic subtyping for

effect analysis: The static semantics. In Analysis and Verification of
Multiple-Agent Languages, volume 1192 of Lecture Notes in Computer
[135] L. Pacholski and A. Podelski. Set constraints: A pearl in research on
constraints. In Proc. Third International Conference on the Principles
and Practice of Constraint Programming, volume 1330 of Lecture Notes
in Computer Science, pages 549-561. Springer, 1997.
[136] J. Palsberg. Closure analysis in constraint form. ACM TOPLAS, 17
(1):47-62, 1995.
[137] J. Palsberg and M. I. Schwartzbach. Object-Oriented Type Systems.
Wiley, 1994.
[138] H. D. Pande and B. G. Ryder. Data-flow-based virtual function reso-
lution. In Proc. SAS '96, volume 1145 of Lecture Notes in Computer
[139] J. Plevyak and A. A. Chien. Precise concrete type inference of object-
oriented programs. In Proc. OOPSLA '94, 1994.
[140] G. D. Plotkin. A structural approach to operational semantics. Tech-
nical Report FN-19, DAIMI, Aarhus University, Denmark, 1981.
[141] G. Ramalingam, J. Field, and F. Tip. Aggregate structure identification
and its application to program analysis. In Proc. POPL '99, pages 119-
132. ACM Press, 1999.
[142] J. H. Reif and S. A. Smolka. Data Flow Analysis of Distributed Com-
municating Processes. International Journal of Parallel Programming,
19(1):1-30, 1990.
[143] J. Reynolds. Automatic computation of data set definitions. In Infor-
mation Processing, volume 68, pages 456-461. North Holland, 1969.
[144] B. K. Rosen. High-level data flow analysis. Communications of the
ACM, 20(10):141-156, 1977.
[145] E. Ruf. Context-insensitive alias analysis reconsidered. In Proc. PLDI
'95, pages 13-22. ACM Press, 1995.
[146] B. G. Ryder and M. C. Paull. Elimination algorithms for data flow
analysis. ACM Computing Surveys, 18(3):275-316, 1986.
[147] M. Sagiv, T. Reps, and S. Horwitz. Precise interprocedural dataflow
analysis with applications to constant propagation. In Proc. TAPSOFT
'95, volume 915 of Lecture Notes in Computer Science, pages 651-665,
1995.
450 Bibliography
[148] M. Sagiv, T. Reps, and R. Wilhelm. Solving shape-analysis problems in

languages with destructive updating. In Proc. POPL '96, pages 16-31.
ACM Press, 1996.
[149] M. Sagiv, T. Reps, and R. Wilhelm. Solving shape-analysis problems

in languages with destructive updating. ACM TOPLAS, 20(1):1-50,
1998.
[150] M. Sagiv, T. Reps, and R. Wilhelm. Parametric shape analysis via

3-valued logic. In Proc. POPL '99, pages 105-118. ACM Press, 1999.
[151] D. Schmidt. Data flow analysis is model checking of abstract interpre-

tations. In Proc. POPL '98, pages 38-48. ACM Press, 1998.
[152] P. Sestoft. Replacing function parameters by global variables. Master's

thesis, Department of Computer Science, University of Copenhagen,
Denmark, 1988.
[153] M. Shapiro and S. Horwitz. Fast and accurate flow-insensitive points-to

analysis. In Proc. POPL '97, pages 1-14. ACM Press, 1997.
[154] M. Sharir. Structural Analysis: a New Approach to Flow Analysis in

Optimising Compilers. Computer Languages, 5:141-153, 1980.
[155] M. Sharir and A. Pnueli. Two approaches to interprocedural data flow

analysis. In S. S. Muchnick and N. D. Jones, editors, Program Flow
Analysis. Prentice Hall International, 1981.
[156] O. Shivers. Control flow analysis in Scheme. In Proc. PLDI '88, volume
7 (1) of ACM SIGPLAN Notices, pages 164-174. ACM Press, 1988.
[157] O. Shivers. Data-flow analysis and type recovery in Scheme. In P.Lee,

editor, In Topics in Advanced Language lmplementation, pages 47-87.
MIT Press, 1991.
[158] O. Shivers. The semantics of Scheme control-flow analysis. In

Proc. PEPM '91, volume 26 (9) of ACM SIGPLAN Notices. ACM
Press, 1991.
[159] J. H. Siekmann. Unification theory. Journal of Symbolic Computation,

7:207-274, 1989.
[160] G. S. Smith. Polymorphic type inference with overloading and subtyp-

ing. In Proc. TAPSOFT '93, volume 668 of Lecture Notes in Computer
[161] G. S. Smith. Principal type schemes for functional programs with over-
loading and subtyping. Science of Computer Programming, 23:197-226,
1994.
Bibliography 451
[162] B. Steensgaard. Points-to analysis in almost linear time. In Proc. POPL

'96, pages 32-41. ACM Press, 1996.
[163] D. Stefanescu and Y. Zhou. An equational framework for the flow

analysis of higher order functional programs. In Proc. LFP '94, pages
318-327, 1994.
[164] B. Steffen. Generating data flow analysis algorithms from modal spec-
ifications. Science of Computer Programming, 21:115-239, 1993.
[165] J. Stransky. A lattice for abstract interpretation of dynamic (lisp-like)

structures. lnformation and Computation, 1990.
[166] J.-P. Talpin and P. Jouvelot. Polymorphic Type, Region and Effect
Inference. Journal of Functional Programming, 2(3):245-271, 1992.
[167] J.-P. Talpin and P. Jouvelot. The type and effect discipline. In
Proc. LICS '92, pages 162-173, 1992.
[168] J.-P. Talpin and P. Jouvelot. The type and effect discipline. lnformation
and Computation, 111(2):245-296, 1994.
[169] Y.-M. Tang. Control-Flow Analysis by Effect Systems and Abstract

Interpretation. PhD thesis, Ecole des Mines de Paris, 1994.
[170] R. E. Tarjan. Fast algorithms for solving path problems. Journal of

the ACM, 28(3):594-614, 1981.
[171] R. E. Tarjan. A unified approach to path programs. Journal of the

ACM, 28(3):577-593, 1981.
[172) S. Tjiang and J. Hennessy. Sharlit - a tool for building optimizers. In
Proc. PLDI '92. ACM Press, 1992.
[173] M. Tofte. Type inference for polymorphic references. Information and

Computation, 89:1-34, 1990.
[174] M. Tofte and L. Birkedal. A region inference algorithm. ACM

TOPLAS, 20(3):1-44, 1998.
[175] M. Tofte and J.-P. Talpin. Implementing the call-by-value lambda-

calculus using a stack of regions. In Proc. POPL '94, pages 188-201.
ACM Press, 1994.
[176] M. Tofte and J.-P. Talpin. Region-based memory management. lnfor-
mation and Computation, 132:109-176, 1997.
[177] G. V. Venkatesh and C. N. Fischer. Spare: A development environ-

ment for program analysis algorithms. IEEE Transactions on Software
Engineering, 1992.
452 Bibliography
[178] J. Vitek, R. N. Horspool, and J. S. Uhl. Compile-Time Analysis of

Object-Oriented Programs. In Proc. CC '92, volume 641 of Lecture
[179] A. B. Webber. Program analysis using binary relations. In Proc. PLDI
'97, volume 32 (5) of ACM SIGPLAN Notices, pages 249-260. ACM
Press, 1997.
[180] M. N. Wegman and F. K. Zadeck. Constant propagation with condi-

tiona! branches. ACM TOPLAS, pages 181-210, 1991.
[181] R. Wilhelm and D. Maurer. Compiler Design. Addison-Wesley, 1995.
[182] R. P. Wilson and M. S. Lam. Efficient context-sensitive pointer analysis

for C programs. In Proc. PLDI '95, pages 1-12. ACM Press, 1995.
[183] A. K. Wright. Typing references by effect inference. In Proc. ESOP
Springer, 1992.
[184] A. K. Wright and M. Felleisen. A syntactic approach to type soundness.

Information and Computation, 115:38-94, 1994.
[185] K. Yi and W. L. Harrison III. Automatic generation and management

of interprocedural program analyses. In Proc. POPL '93, pages 246-
259. ACM Press, 1993.

Principles of Program Analysis - Flemming Nielson, Hanne Riis Nielson, Chris Hankin

Uploaded by

Copyright:

Available Formats

Principles of Program Analysis - Flemming Nielson, Hanne Riis Nielson, Chris Hankin

Uploaded by

Document Information

Original Title

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

Principles of Program Analysis - Flemming Nielson, Hanne Riis Nielson, Chris Hankin

Uploaded by

Copyright:

Available Formats

What is the subject matter covered in the book?

What is the subject matter covered in the book?

What are some of the approaches to program analysis discussed in the book?

What are some of the approaches to program analysis discussed in the book?

Flemming Nielson Hanne Riis Nielson

Cataloging-in-Publication data applied for

© Springer-Verlag Berlin Heidelberg 1999, 2005

Typesetting: Camera-ready by the authors

How to read the book. The book is relatively self-contained although

Chapter 3 covers Constraint Based Analysis. The treatment makes a clear

Four or five lectures should suffice for a complete treatment of Chapter 4 as

Acknowledgements. We should like to thank Reinhard Wilhelm for

Aarhus and London Flemming Nielson

Preface to the second printing. In this second printing we have

Official web page. Further information about the book is available at

provide information about availability of the book, a list of misprints (initially

Lyngby and London Flemming Nielson

2 Data Flow Analysis 35

2.2 Theoretical Properties . . . . . . . . . . . 54

3 Constraint Based Analysis 141

3.2.4 Coinduction versus Induction 165

4 Abstract Interpretation 211

4.5.2 Application to Data Flow Analysis . . . . . 262

5 Type and Effect Systems 283

6.2.1 The Round Robin Algorithm . 378

A Partially Ordered Sets 393

B Induction and Coinduction 405

c Graphs and Regular Expressions 417

Index of N otation 429

1.1 Reaching Definitions information for the factorial program. 4

2.1 Available Expressions Analysis. 40

308 Abstract values as powersetso o o o o 184

501 The Underlying Type Systemo o 285

601 The Abstract Worklist Algorithmo 369

Co1 The DFSF Algorithmo o o o o o o o o o 421

1.1 The nature of approximation: erring on the safe side. . 2

2.1 Flow graph for the power program. 38

3.1 Pictorial illustration of the clauses [let] and [var]. 148

4.1 Correctness relation R generated by representation function (3. 218

5.1 The memory model for the stack-based implementation of FuN.331

6.1 Example: LIFO iteration. . . . . . . . . . . . . . . . . . . . 374

A.1 Two complete lattices. . . . 394

C.l A fl.ow graph . . . . . . . . . . . . . . . 422

In this book we shall introduce four of the main approaches to program

1.1 The Nature of Program Analysis

Figure 1.1: The nature of approximation: erring on the safe side.

that there is a large amount of commonality among the approaches. This

read(x); (if x>O then y:=l else (y:=2;S)); z:=y

where S is some statement that does not contain an assignment to y. Intu-

1.2 Setting the Scene

Table 1.1: Reaching Definitions information for the factorial program.

opa E Opa arithmetic operators

Example 1.1 An example of a program written in this language is the

Reaching Definitions Analysis. The use of distinct labels allows

An assignment (called a definition in the classical literature) of

1.3 Data Flow Analysis

1.3.1 The Equational Approach

Figure 1.2: Flow graph for the factorial program.

S1 : R01 , R02 S2 : R02 , R03

S1 : R01 , R02 S2 : R01 , R02