The Complexity of Flow Analysis in Higher-Order Languages · 2013-11-20 · The Complexity of Flow Analysis in Higher-Order Languages A Dissertation Presented to The Faculty of the

The Complexity of Flow Analysis inHigher-Order Languages

David Van Horn

arX

iv:1

311.

4733

v1 [

cs.P

L]

19

Nov

201

3

The Complexity of Flow Analysis inHigher-Order Languages

A Dissertation

Presented toThe Faculty of the Graduate School of Arts and Sciences

Brandeis UniversityMitchom School of Computer Science

In Partial Fulfillmentof the Requirements for the Degree

Doctor of Philosophy

byDavid Van Horn

August, 2009

This dissertation, directed and approved by David Van Horn’s committee, hasbeen accepted and approved by the Graduate Faculty of Brandeis University inpartial fulfillment of the requirements for the degree of:

DOCTOR OF PHILOSOPHY

Adam B. Jaffe, Dean of Arts and Sciences

Dissertation Committee:

Harry G. Mairson, Brandeis University, ChairOlivier Danvy, University of AarhusTimothy J. Hickey, Brandeis UniversityOlin Shivers, Northeastern University

c© David Van Horn, 2009Licensed under the Academic Free License version 3.0.

in memory of William Gordon MercerJuly 22, 1927–October 8, 2007

Acknowledgments

Harry taught me so much, not the least of which was a compelling kind of science.

It is fairly obvious that I am not uninfluenced by Olivier Danvy and Olin Shiversand that I do not regret their influence upon me.

My family provided their own weird kind of emotional support and humor.

I gratefully acknowledge the support of the following people, groups, and institu-tions, in no particular order: Matthew Goldfield. Jan Midtgaard. Fritz Henglein.Matthew Might. Ugo Dal Lago. Chung-chieh Shan. Kazushige Terui. ChristianSkalka. Shriram Krishnamurthi. Michael Sperber. David McAllester. MitchellWand. Damien Sereni. Jean-Jacques Levy. Julia Lawall. Matthias Felleisen.Dimitris Vardoulakis. David Herman. Ryan Culpepper. Richard Cobbe. FelixS Klock II. Sam Tobin-Hochstadt. Patrick Cousot. Alex Plotnick. Peter MøllerNeergaard. Noel Welsh. Yannis Smaragdakis. Thomas Reps. Assaf Kfoury. Jef-frey Mark Siskind. David Foster Wallace. Timothy J. Hickey. Myrna Fox. JeanneDeBaie. Helene Greenberg. Richard Cunnane. Larry Finkelstein. Neil D. Jonesand the lecturers of the Program Analysis and Transformation Summer Schoolat DIKU. New England Programming Languages and Systems Symposium. IBMProgramming Language Day. Northeastern University Semantics Seminar and PLJr. Seminar series. The reviewers of ICFP’07, SAS’08, and ICFP’08. Northeast-ern University. Portland State University. The National Science Foundation, grantCCF-0811297.

And of course, Jessie. All the women in the world aren’t whores, just mine.

xi

Abstract

This dissertation proves lower bounds on the inherent difficulty of deciding flowanalysis problems in higher-order programming languages. We give exact char-acterizations of the computational complexity of 0CFA, the kCFA hierarchy, andrelated analyses. In each case, we precisely capture both the expressiveness andfeasibility of the analysis, identifying the elements responsible for the trade-off.

0CFA is complete for polynomial time. This result relies on the insight that when aprogram is linear (each bound variable occurs exactly once), the analysis makes noapproximation; abstract and concrete interpretation coincide, and therefore pro-gram analysis becomes evaluation under another guise. Moreover, this is true notonly for 0CFA, but for a number of further approximations to 0CFA. In each case,we derive polynomial time completeness results.

For any k > 0, kCFA is complete for exponential time. Even when k = 1, thedistinction in binding contexts results in a limited form of closures, which donot occur in 0CFA. This theorem validates empirical observations that kCFA isintractably slow for any k > 0. There is, in the worst case—and plausibly, inpractice—no way to tame the cost of the analysis. Exponential time is required.The empirically observed intractability of this analysis can be understood as beinginherent in the approximation problem being solved, rather than reflecting unfor-tunate gaps in our programming abilities.

xiii

Preface

What to expect, What not to expect

This dissertation investigates lower bounds on the computational complexity offlow analysis for higher-order languages, uncovering its inherent computationalcosts and the fundamental limits of efficiency for any flow analysis algorithm.As such, I have taken existing, representative, flow analysis specifications “offthe shelf” without modification. This is not a dissertation on the design andimplementation of novel flow analyses (although it should inform such work).The reader is advised to expect no benchmarks or prototype implementations, butrather insightful proofs and theorems.

This dissertation relates existing research in order to situate the novelty and sig-nificance of this work. It does not attempt to comprehensively survey the nearlythirty years of research on flow analysis, nor the wealth of frameworks, formula-tions, and variants. A thorough survey on flow analysis has been undertaken byMidtgaard (2007).

Assumptions on the reader

For the reader expecting to understand the intuitions, proofs, and consequences ofthe results of this dissertation, I assume familiarity with the following, in roughlydescending order of importance:

• functional programming.

The reader should be at ease programming with higher-order proceduresin languages such as Scheme or ML. For an introduction to programming

xv

PREFACE

in Scheme specifically, The Scheme Programming Language by Dybvig(2002) and Teach Yourself Scheme in Fixnum Days by Sitaram (2004) arerecommended; for ML, Programming in Standard ML by Harper (2005)and ML for Working Programmer by Paulson (1996) are recommended.

This dissertation relies only on the simplest applicative subsets of these lan-guages.

• interpreters (evaluators).

The reader should understand the fundamentals of writing an interpreter, inparticular an environment-based interpreter (Landin 1964) for the functionalcore of a programming language.1 The definitive reference is “Definitionalinterpreters for higher-order programming languages” by Reynolds (1972,1998). Understanding sections 2–6 are an absolute must (and joy). Fora more in-depth textbook treatment, see the gospel according to Abelsonand Sussman (1996): Structure and Interpretation of Computer Programs,Chapter 3, Section 2, “The Environment Model of Evaluation,” and Chapter4, Section 1, “The Metacircular Evaluator.” Finally, Essentials of Program-ming Languages by Friedman and Wand (2008) is highly recommended.2

• the λ-calculus.

The encyclopedic reference is The Lambda Calculus: Its Syntax and Se-mantics by Barendregt (1984), which is an overkill for the purpose of un-derstanding this dissertation. Chapters 1 and 3 of Lectures on the Curry-Howard Isomorphism by Sørensen and Urzyczyn (2006) offers a conciseand sufficient introduction to untyped and typed λ-calculus, respectively.There are numerous others, such as An Introduction to Lambda Calculifor Computer Scientists by Hankin (2004), Functional programming andlambda calculus by Barendregt (1990), and so on. Almost any will do.3

• basic computational complexity theory.

The reader should be familiar with basic notions such as complexity classes,Turing machines, undecidability, hardness, and complete problems. Pa-padimitriou (1994) is a standard introduction (See chapters 2–4, 7–9, 15,

1Note that almost every modern programming language includes a higher-order, functional core:Scheme, ML, JavaScript, Java, Haskell, Smalltalk, Ruby, C#, etc., etc.

2As an undergraduate, I cut my teeth on the first edition (1992).3See Cardone and Hindley (2006, Footnote 1) for references to French, Japanese, and Russianoverviews of the λ-calculus.

xvi

PREFACE

and 16). Jones (1997) is a good introduction with a stronger emphasis onprogramming and programming languages (See part IV and V). Almost anydecent undergraduate text on complexity would suffice.

In particular, the classes LOGSPACE, PTIME, NPTIME, and EXPTIME areused. Reductions are given from canonical complete problems for theseclasses to various flow analysis problems. These canonical complete prob-lems include, respectively: the permutation problem, circuit value problem(CVP), Boolean satisfiability (SAT), and a generic reduction for simulatingdeterministic, exponential time Turing machines.

Such a reduction from a particular complete computational problem to acorresponding flow analysis problem establishes a lower bound on the com-plexity of flow analysis: solving the flow problem is at least as hard as solv-ing the corresponding computational problem (SAT, CVP, etc.), since anyinstance of these problems can be transformed (reduced), using very limitedresources, to an instance of the flow analysis problem. In other words, analgorithm to solve one problem can be used as an algorithm to solve theother.

• fundamentals of program analysis.

A basic understanding of program analysis would be beneficial, althoughI have tried to make plain the connection between analysis and evaluation,so a thorough understanding of program interpretation could be sufficient.Perhaps the standard text on the subject is Principles of Program Analysisby Nielson et al. (1999), which I have followed closely because it offers anauthoritative and precise definition of flow analysis. It is thorough and rig-orous, at the risk of slight rigor mortis. Shivers’ dissertation, Control-FlowAnalysis of Higher-Order Languages, contains the original development ofkCFA and is replete with intuitions and explanations.

• logic and proof theory.

The reader should be comfortable with the basics of propositional logic,such as De Morgan duality, modus ponens, etc. The reader is also assumedto be comfortable with sequent calculi, and in particular sequents for linearlogic. Girard et al. (1989) provides a solid and accessible foundation.

All of the theorems will be accessible, but without this background, only asmall number of the more supplemental proofs will be inaccessible. Fearnot if this is not your cup of meat.

xvii

PREFACE

Previously published material

Portions of this dissertation are derived from material previously published in thefollowing papers, written jointly with Harry Mairson:

1. Relating Complexity and Precision in Control Flow Analysis. In Proceed-ings of the 12th International Conference on Functional Programming, Frieburg,Germany. Van Horn and Mairson (2007).

2. Flow Analysis, Linearity, and PTIME. In The 15th International Static Anal-ysis Symposium, Valencia, Spain. Van Horn and Mairson (2008b).

3. Deciding kCFA is complete for EXPTIME. In Proceedings of the 13th In-ternational Conference on Functional Programming, Victoria, BC, Canada.Van Horn and Mairson (2008a).

xviii

Contents

Acknowledgments xi

Abstract xiii

Preface xv

Contents xix

List of Figures xxiii

1 Introduction 31.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Summary of Results . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Linearity, Analysis and Normalization . . . . . . . . . . . 61.3.2 Monovariance and PTIME . . . . . . . . . . . . . . . . . 61.3.3 0CFA with η-Expansion and LOGSPACE . . . . . . . . . . 71.3.4 kCFA and EXPTIME . . . . . . . . . . . . . . . . . . . . 7

2 Foundations 92.1 Structure and Interpretation . . . . . . . . . . . . . . . . . . . . . 92.2 Instrumented Interpretation . . . . . . . . . . . . . . . . . . . . . 122.3 Abstracted Interpretation . . . . . . . . . . . . . . . . . . . . . . 172.4 Computational Complexity . . . . . . . . . . . . . . . . . . . . . 22

2.4.1 Why a Complexity Investigation? . . . . . . . . . . . . . 222.4.2 Complexity Classes . . . . . . . . . . . . . . . . . . . . . 25

2.5 Proving Lower Bounds: The Art of Exploitation . . . . . . . . . . 27

3 Monovariant Analysis and PTIME 31

xix

CONTENTS

3.1 The Approximation of Monovariance . . . . . . . . . . . . . . . 313.2 0CFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Henglein’s Simple Closure Analysis . . . . . . . . . . . . . . . . 363.4 Linearity: Analysis is Evaluation . . . . . . . . . . . . . . . . . . 383.5 Lower Bounds for Flow Analysis . . . . . . . . . . . . . . . . . . 443.6 Other Monovariant Analyses . . . . . . . . . . . . . . . . . . . . 49

3.6.1 Ashley and Dybvig’s Sub-0CFA . . . . . . . . . . . . . . 503.6.2 Subtransitive 0CFA . . . . . . . . . . . . . . . . . . . . . 50

3.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4 Linear Logic and Static Analysis 534.1 Sharing Graphs for Static Analysis . . . . . . . . . . . . . . . . . 544.2 Graphical 0CFA . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3 Multiplicative Linear Logic . . . . . . . . . . . . . . . . . . . . . 59

4.3.1 Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3.2 Programs . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4 η-Expansion and LOGSPACE . . . . . . . . . . . . . . . . . . . . 624.4.1 Atomic versus Non-Atomic Axioms . . . . . . . . . . . . 624.4.2 Proof Normalization with Non-Atomic Axioms: PTIME . . 644.4.3 Proof Normalization with Atomic Axioms: LOGSPACE . . 664.4.4 0CFA in LOGSPACE . . . . . . . . . . . . . . . . . . . . 674.4.5 LOGSPACE-hardness of Normalization and 0CFA: linear,

simply-typed, fully η-expanded programs . . . . . . . . . 684.5 Graphical Flow Analysis and Control . . . . . . . . . . . . . . . 70

5 kCFA and EXPTIME 735.1 Shivers’ kCFA . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.2 kCFA is in EXPTIME . . . . . . . . . . . . . . . . . . . . . . . . 765.3 kCFA is NPTIME-hard . . . . . . . . . . . . . . . . . . . . . . . 775.4 Nonlinearity and Cartesian Products:

a toy calculation, with insights . . . . . . . . . . . . . . . . . . . 795.5 kCFA is EXPTIME-hard . . . . . . . . . . . . . . . . . . . . . . . 80

5.5.1 Approximation and EXPTIME . . . . . . . . . . . . . . . 805.5.2 Coding Machine IDs . . . . . . . . . . . . . . . . . . . . 815.5.3 Transition Function . . . . . . . . . . . . . . . . . . . . . 825.5.4 Context and Widget . . . . . . . . . . . . . . . . . . . . 84

5.6 Exact kCFA is PTIME-complete . . . . . . . . . . . . . . . . . . 855.7 Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

xx

CONTENTS

5.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6 Related Work 916.1 Monovariant Flow Analysis . . . . . . . . . . . . . . . . . . . . . 916.2 Linearity and Static Analysis . . . . . . . . . . . . . . . . . . . . 926.3 Context-Free-Language Reachability . . . . . . . . . . . . . . . . 936.4 2NPDA and the Cubic Bottleneck . . . . . . . . . . . . . . . . . 956.5 kCFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.6 Class Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.7 Pointer Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.8 Logic Programming . . . . . . . . . . . . . . . . . . . . . . . . . 1046.9 Termination Analysis . . . . . . . . . . . . . . . . . . . . . . . . 1046.10 Type Inference and Quantifier Elimination . . . . . . . . . . . . . 105

7 Conclusions and Perspective 1117.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.2.1 Completing the Pointer Analysis Complexity Story . . . . 1127.2.2 Polyvariant, Polynomial Flow Analyses . . . . . . . . . . 1137.2.3 An Expressive Hierarchy of Flow Analyses . . . . . . . . 1137.2.4 Truly Subcubic Inclusion-Based Flow Analysis . . . . . . 1147.2.5 Toward a Fundamental Theorem of Static Analysis . . . . 114

Bibliography 117

Colophon 141

xxi

List of Figures

2.1 Evaluator E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Instrumented evaluator I, imperative style. . . . . . . . . . . . . . 152.3 Instrumented evaluator I, functional style. . . . . . . . . . . . . . 162.4 Exact cache acceptability, or Instrumented evaluator I, declara-

tive style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 Abstract evaluator A, imperative style. . . . . . . . . . . . . . . . 192.6 Abstract evaluator A, functional style. . . . . . . . . . . . . . . . 202.7 Abstract cache acceptability, or Abstract evaluator A, declarative

style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 0CFA abstract cache acceptability. . . . . . . . . . . . . . . . . . 343.2 Abstract evaluator A0 for 0CFA, imperative style. . . . . . . . . . 353.3 Simple closure analysis abstract cache acceptability. . . . . . . . . 373.4 Evaluator E ′. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5 Abstract evaluator A0 for 0CFA, functional style. . . . . . . . . . 413.6 An example circuit. . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1 CFA virtual wire propagation rules. . . . . . . . . . . . . . . . . 564.2 Graph coding and CFA graph of (λf.ff(λy.y))(λx.x). . . . . . . 584.3 MLL sequent rules. . . . . . . . . . . . . . . . . . . . . . . . . . 614.4 Expansion algorithm. . . . . . . . . . . . . . . . . . . . . . . . . 634.5 MLL proofnets. . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.6 MLL proofnet with atomic axioms. . . . . . . . . . . . . . . . . . 654.7 Graph coding of call/cc and example CFA graph. . . . . . . . 71

5.1 NPTIME-hard construction for kCFA. . . . . . . . . . . . . . . . . 775.2 Generalization of toy calculation for kCFA. . . . . . . . . . . . . 815.3 Turing machine transition function construction. . . . . . . . . . . 83

xxiii

LIST OF FIGURES

5.4 EXPTIME-hard construction for kCFA. . . . . . . . . . . . . . . . 84

6.1 Translation of kCFA EXPTIME-construction into an object-orientedlanguage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

1

Chapter 1

Introduction

We analyze the computational complexity of flow analysis for higher-order lan-guages, yielding a number of novel insights: kCFA is provably intractable; 0CFAand its approximations are inherently sequential; and analysis and evaluation oflinear programs are equivalent.

1.1 Overview

Predicting the future is hard.

Nevertheless, such is the business of an optimizing compiler: it reads in an inputprogram, predicts what will happen when that program is run, and then—basedon that prediction—outputs an optimized program.

Often these predictions are founded on semantics-based program analysis (Cousotand Cousot 1977, 1992; Muchnick and Jones 1981; Nielson et al. 1999), whichaims to discover the run-time behavior of a program without actually running it(Muchnick and Jones 1981, page xv). But as a natural consequence of Rice’stheorem (1953), a perfect prediction is almost always impossible. So tractableprogram analysis must necessarily trade exact evaluation for a safe, computableapproximation to it. This trade-off induces a fundamental dichotomy at play inthe design of program analyzers and optimizing compilers. On the one hand,the more an analyzer can discover about what will happen when the program isrun, the more optimizations the compiler can perform. On the other, compilers

3

CHAPTER 1. INTRODUCTION

are generally valued not only for producing fast code, but doing so quickly andefficiently; some optimizations may be forfeited because the requisite analysis istoo difficult to do in a timely or space-efficient manner.

As an example in the extreme, if we place no limit on the resources consumed bythe compiler, it can perfectly predict the future—the compiler can simply simulatethe running of the program, watching as it goes. When (and if) the simulationcompletes, the compiler can optimize with perfect information about what willhappen when the program is run. With good reason, this seems a bit like cheating.

So at a minimum, we typically expect a compiler will eventually finish workingand produce an optimized program. (In other words, we expect the compiler tocompute within bounded resources of time and space). After all, what good is anoptimizing compiler that never finishes?

But by requiring an analyzer to compute within bounded resources, we have nec-essarily and implicitly limited its ability to predict the future.

As the analyzer works, it must use some form of approximation; knowledge mustbe given up for the sake of computing within bounded resources. Further resource-efficiency requirements may entail further curtailing of knowledge that a programanalyzer can discover. But the relationship between approximation and efficiencyis far from straightforward. Perhaps surprisingly, as has been observed empiricallyby researchers (Wright and Jagannathan 1998; Jagannathan et al. 1998; Mightand Shivers 2006b), added precision may avoid needless computation induced byapproximation in the analysis, resulting in computational savings—that is, betterinformation can often be produced faster than poorer information. So what exactlyis the analytic relationship between forfeited information and resource usage forany given design decision?

In trading exact evaluation for a safe, computable approximation to it, analysisnegotiates a compromise between complexity and precision. But what exactly arethe trade-offs involved in this negotiation? For any given design decision, what isgiven up and what is gained? What makes an analysis rich and expressive? Whatmakes an analysis fast and resource-efficient?

We examine these questions in the setting of flow analysis (Jones 1981; Sestoft1988, 1989; Shivers 1988, 1991; Midtgaard 2007), a fundamental and ubiquitousstatic analysis for higher-order programming languages. It forms the basis of al-most all other analyses and is a much-studied component of compiler technology.

4


Flow analysis answers basic questions such as “what functions can be applied?,”and “to what arguments?” These questions specify well-defined, significant deci-sion problems, quite apart from any algorithm proposed to solve them. This disser-tation examines the inherent computational difficulty of deciding these problems.

If we consider the most useful analysis the one which yields complete and per-fectly accurate information about the running of a program, then clearly this anal-ysis is intractable—it consumes the same computational resources as running theprogram. At the other end of the spectrum, if the least useful analysis yields noinformation about the running of a program, then this analysis is surely feasible,but useless.

If the design of software is really a science, we have to understand the trade-offsbetween the running time of static analyzers, and the accuracy of their computa-tions.

There is substantial empirical experience, which gives a partial answer to thesequestions. However, despite being the fundamental analysis of higher-order pro-grams, despite being the subject of investigation for over twenty-five years, andthe great deal of expended effort deriving clever ways to tame the cost, there hasremained a poverty of analytic knowledge on the complexity of flow analysis, theessence of how it is computed, and where the sources of approximation occur thatmake the analysis work.

This dissertation is intended to repair such lacunae in our understanding.

1.2 Summary of Results

• Normalization and analysis are equivalent for linear programs.

• 0CFA and other monovariant flow analyses are complete for PTIME.

• 0CFA of typed, η-expanded programs is complete for LOGSPACE.

• kCFA is complete for EXPTIME for all k > 0.

5


1.3 Details

1.3.1 Linearity, Analysis and Normalization

• Normalization and analysis are equivalent for linear programs.

Although variants of flow analysis abound, we identify a core language, the linearλ-calculus, for which all of these variations coincide. In other words, for linearprograms—those written to use each bound variable exactly once—all known flowanalyses will produce equivalent information.

It is straightforward to observe that in a linear λ-term, each abstraction λx.e canbe applied to at most one argument, and hence the abstracted value can be boundto at most one argument. Generalizing this observation, analysis of a linear λ-term coincides exactly with its evaluation. So not only are the varying analysesequivalent to each other on linear terms, they are all equivalent to evaluation.

Linearity is an equalizer among variations of static analysis, and a powerful toolin proving lower bounds.

1.3.2 Monovariance and PTIME

• 0CFA and other monovariant flow analyses are complete for PTIME.

By definition, a monovariant analysis (e.g. 0CFA), does not distinguish betweenoccurrences of the same variable bound in different calling contexts. But thedistinction is needless for linear programs and analysis becomes evaluation underanother name. This opens the door to proving lower bounds on the complexityof the analysis by writing—to the degree possible—computationally intensive,linear programs, which will be faithfully executed by the analyzer rather than theinterpreter.

We rely on a symmetric coding of Boolean logic in the linear λ-calculus to simu-late circuits and reduce the 0CFA decision problem to the canonical PTIME prob-lem, the circuit value problem. This shows, since the inclusion is well-known,that 0CFA is complete for PTIME. Consequently, 0CFA is inherently sequentialand there is no fast parallel algorithm for 0CFA (unless PTIME = NC). Moreover,this remains true for a number of further approximations to 0CFA.

6


The best known algorithms for computing 0CFA are often not practical for largeprograms. Nonetheless, information can be given up in the service of quicklycomputing a necessarily less precise analysis. For example, by forfeiting 0CFA’snotion of directionality, algorithms for Henglein’s simple closure analysis run innear linear time (1992). Similarly, by explicitly bounding the number of passesthe analyzer is allowed over the program, as in Ashley and Dybvig’s sub-0CFA(1998), we can recover running times that are linear in the size of the program. Butthe question remains: Can we do better? For example, is it possible to computethese less precise analyses in logarithmic space? We show that without profoundcombinatorial breakthroughs (PTIME = LOGSPACE), the answer is no. Simpleclosure analysis, sub-0CFA, and other analyses that approximate or restrict 0CFA,require—and are therefore, like 0CFA, complete for—polynomial time.

1.3.3 0CFA with η-Expansion and LOGSPACE

• 0CFA of typed, η-expanded programs is complete for LOGSPACE.

We identify a restricted class of functional programs whose 0CFA decision prob-lem may be simpler—namely, complete for LOGSPACE. Consider programs thatare simply typed, and where a variable in the function position or the argumentposition of an application is fully η-expanded. This case—especially, but not onlywhen the programs are linear—strongly resembles multiplicative linear logic withatomic axioms.

We rely on the resemblance to bring recent results on the complexity of normal-ization in linear logic to bear on the analysis of η-expanded programs resulting ina LOGSPACE-complete variant of 0CFA.

1.3.4 kCFA and EXPTIME

• kCFA is complete for EXPTIME for all k > 0.

We give an exact characterization of the computational complexity of the kCFAhierarchy. For any k > 0, we prove that the control flow decision problem iscomplete for deterministic exponential time. This theorem validates empirical

7


observations that such control flow analysis is intractable. It also provides moregeneral insight into the complexity of abstract interpretation.

A fairly straightforward calculation shows that kCFA can be computed in expo-nential time. We show that the naive algorithm is essentially the best one. Thereis, in the worst case—and plausibly, in practice—no way to tame the cost of theanalysis. Exponential time is required.

8

Chapter 2

Foundations

The aim of flow analysis is to safely approximate an answer the question:1

For each function application, which functions may be applied?

Analysis can easily be understood as the safe approximation to program evalua-tion. It makes sense, then, to first consider evaluation in detail. In the followingsections, an evaluation function (E) is defined, from which an instrumented varia-tion (I) is derived and abstracted to obtain the abstract evaluator (A). Finally, wereview basic concepts from complexity theory and sketch our approach to provinglower bounds.

2.1 Structure and Interpretation

The meaningful phrases of a program are called expressions, the process of ex-ecuting or interpreting these expressions is called evaluation, and the result ofevaluating an expression is called a value (Reynolds 1972).

We will consider a higher-order applicative programming language based on theλ-calculus, in which evaluation is environment based and functional values are

1See for example the transparencies accompanying Chapter 3 “Control Flow Analysis” of Nielsonet al. (1999): http://www2.imm.dtu.dk/∼riis/PPA/ppa.html

9

http://www2.imm.dtu.dk/~riis/PPA/ppa.html

CHAPTER 2. FOUNDATIONS

represented using closures. The syntax of the language is given by the followinggrammar:

Exp e ::= x | e e | λx.e expressions

Note to the reader: This may seem a rather minimal programminglanguage and you may wonder what the broader applicability of theseresults are in the face of other language features. But as noted earlier,this dissertation is concerned with lower bounds on static analysis.By examining a minimal, core language, all results will immediatelyapply to any language which includes this core. In other words, themore restricted the subject language, the broader the applicability.

It may be that the lower bound can be improved in the presence ofsome language features, that is, the given set of features may makeanalysis provably harder, but it certainly can not make it any easier.2

Following Landin (1964), substitution is modelled using environments. Proce-dures will be represented as closures, a λ-term together with its lexical environ-ment, which closes over the free variables in the term, binding variables to values.

We use ρ to range over environments (mappings from variables to closures), and vto range over closures (pairs consisting of a term and an environment that closesthe term). The empty environment (undefined on all variables) is denoted •, andwe occasionally abuse syntax and write the closed term e in place of the closure〈e, •〉. Environment extension is written ρ[x 7→ v] and we write •[x 7→ v] as[x 7→ v] and [x1 7→ v1] . . . [xn 7→ vn] as [x1 7→ v1, . . . , xn 7→ vn].

Env ρ ∈ Var⇀ Val environmentsVal v ∈ 〈Exp,Env〉 closures

2This is to be contrasted with, for example, a type soundness theorem, where it is just the opposite:adding new language feature may revoke soundness.

For similar remarks, see the discussion in section 2 of Reps (1996) concerning the benefits offormulating an analysis problem in “trimmed-down form,” which not only leads to a wider appli-cability of the lower bounds, but also “allows one to gain greater insight into exactly what aspectsof an interprocedural-analysis problem introduce what computational limitations on algorithmsfor these problems.”

In other words, lower bounds should be derived not by piling feature on top of feature, but byremoving the weaknesses and restrictions that make additional features appear necessary.

10


E : Exp× Env ⇀ Val

EJxKρ = ρ(x)EJλx.eKρ = 〈λx.e, ρ′〉

where ρ′ = ρ� fv(λx.e)EJe1e2Kρ = let 〈λx.e0, ρ

′〉 = EJe1Kρ inlet v = EJe2Kρ inEJe0Kρ′[x 7→ v]

Figure 2.1: Evaluator E .

The meaning of an expression is given in terms of an evaluation function, or in-terpreter. Following Abelson and Sussman (1996, Chapter 4, “Metalinguistic Ab-straction”), an interpreter is defined as follows:

An evaluator (or interpreter) for a programming language is a pro-cedure that, when applied to an expression of the language, performsthe actions required to evaluate that expression.

The evaluation function for the language is given in Figure 2.1. We say e evaluatesto v under environment ρ iff EJeKρ = v and computing the evaluation functiondefines our notion of the “running of a program.” Some examples of evaluation:

EJλx.xK• = 〈λx.x, •〉EJ(λx.λz.x)(λy.y)K• = 〈λz.x, [x 7→ 〈λy.y, •〉]〉

EJ(λf.ff(λy.y))(λx.x)K• = 〈λy.y, •〉

This gives us a mostly extensional view of program behaviour—evaluation mapsprograms to values, but offers little information regarding how this value wascomputed. For the sake of program optimization it is much more useful to knowabout operational (or intensional) properties of programs. These properties areformulated by appealing to an “instrumented interpreter,” which is the subjectof the next section. Intuitively, the instrumented evaluator works just like theun-instrumented evaluator, but additionally maintains a complete history of theoperations carried out during the running of the program.

11


2.2 Instrumented Interpretation

Instrumented (or concrete) interpretation carries out the running of program whilemaintaining a trace of the operations performed, thus providing an operationalhistory of evaluation. A suitable reformulation of the original definition of anevaluator to incorporate instrumentation is then:

An instrumented evaluator (or instrumented interpreter) for a pro-gramming language is a procedure that, when applied to an expres-sion of the language, performs and records the actions required toevaluate that expression.

Exactly which actions should be record will vary the domain of any given staticanalysis and there is no universal notion of a program trace, but for flow analysis,the interesting actions are:

• Every time the value of a subexpression is computed, record its value andthe context in which it was evaluated.

• Every time a variable is bound, record the value and context in which it wasbound.

These actions are recorded in a cache, and there is one for each kind of action:

C : Lab×∆ ⇀ Val

r : Var×∆ ⇀ Val

Cache = (Lab×∆ ⇀ Val)× (Var×∆ ⇀ Val)

The C cache records the result, or returned value, of each subcomputation, andthe r cache records each binding of a variable to a value. Given the label of asubexpression (Lab) and a description of the context (∆), C returns the valueproduced by that subexpression evaluated in that context. Given the name of avariable (Var) and a description of the context (∆), r returns the value bound tothat variable in that context. The C cache is a partial function since a subexpres-sion 1) may not produce a value, it may diverge, or 2) may not be evaluated in thegiven context. The r cache is partial for analogous reasons.

12


The set Lab is used to index subexpressions. It can easily be thought of as theimplicit source location of the expression, but our formalism will use an explicitlabelling scheme. We use ` to range over labels. The syntax of the source languageis given by the following grammar, and programs are assumed to be uniquelylabelled:

Exp e ::= t` expressions (or labeled terms)Term t ::= x | (e e) | (λx.e) terms (or unlabeled expressions)

Irrelevant labels are frequently omitted for presentation purposes.

The set ∆ consists of contours, which are strings of labels from application nodesin the abstract syntax of the program. A string of application labels describes thecontext under which the term evaluated.

A variable may be bound to any number of values during the course of evalu-ation. Likewise, a subexpression that occurs once syntactically may evaluate toany number of values during evaluation. So asking about the flows of a subexpres-sion is ambiguous without further information. Consider the following example,where True and False are closed, syntactic values:

(λf.f(f True))(λy.False)

During evaluation, y gets bound to both True and False—asking “what was ybound to?” is ambiguous. But let us label the applications in our term:

((λf.(f(f True)1)2)(λy.False))3

Notice that y is bound to different values within different contexts. That is, yis bound to True when evaluating the application labeled 1, and y is bound toFalse when evaluating the application labeled 2. Both of these occur whileevaluating the outermost application, labeled 3. A string of these application la-bels, called a contour, uniquely describes the context under which a subexpressionevaluates. Adopting the common convention of writing a context as an expressionwith a hole “[ ]” in it (Felleisen and Flatt 2009), the following contours describethe given contexts:

321 describes ((λf.(f [ ]1)2)(λy.False))3

32 describes ((λf.[ ]2)(λy.False))3

So a question about what a subexpression evaluates to within a given context hasan unambiguous answer. The interpreter, therefore, maintains an environment that

13


maps each variable to a description of the context in which it was bound. Simi-larly, flow questions about a particular subexpression or variable binding must beaccompanied by a description of a context. Returning to the example, the bindingcache would give r(y, 321) = True and r(y, 32) = False.

The set Val consists of closures, however the environment component of the clo-sures are non-standard. Rather than mapping variables to values, these environ-ments map variables to contours; the contour describes the context in which thevariable was bound, so the value may be retrieved from the r cache. In other words,these environments include an added layer of indirection through the cache: vari-ables are mapped not to their values but the location of their definition site, wherethe value can be found.

So we have the following data definitions:

δ ∈ ∆ = Lab? contoursv ∈ Val = Term× Env (contour) valuesρ ∈ Env = Var⇀ ∆ (contour) environments

Note that this notation overloads the meaning of Val, Exp, and Env with thatgiven in the previous section. It should be clear from setting which is meant, andwhen both meanings need to be used in the same context, the latter will be referedto as contour values and contour environments.

The cache is computed by the instrumented interpreter, I, the instrumented, in-tentional analog of E . It can be concisely and intuitively written as an imperativeprogram that mutates an initially empty cache, as given in Figure 2.2.

IJt`Kρδ evaluates t and writes the result of evaluation into the C cache at location(`, δ). The notation C(`, δ)← v means that the cache is mutated so that C(`, δ) =v, and similarly for r(x, δ) ← v. The type Unit is used here to emphasize theimperative nature of the instrumented evaluator; no meaningful return value isproduced, the evaluator is run only for effect on the caches. The notation δ`denotes the concatenation of contour δ and label `. The symbol ε denotes theempty contour.

We interpret C(`, δ) = v as saying, “the expression labeled ` evaluates to v in thecontext described by δ,” and r(x, δ) = v as “the variable x is bound to v in thecontext described by δ.” Conversely, we say “v flows to the expression labelled ìnto the context described by δ,” and “v flows to the binding of x in the contextdescribed by δ,” respectively. We refer to a fact such as, C(`, δ) = v or r(x, δ) = v,

14


I : Exp× Env ×∆ ⇀ Unit

IJx`Kρδ = C(`, δ)← r(x, ρ(x))IJ(λx.e)`Kρδ = C(`, δ)← 〈λx.e, ρ′〉

where ρ′ = ρ� fv(λx.e)IJ(t`1t`2)`Kρδ = IJt`1Kρδ ; IJt`2K

ρδ ;

let 〈λx.t`0 , ρ′〉 = C(`1, δ) inr(x, δ`)← C(`2, δ);

IJt`0Kρ′[x 7→δ`]δ` ;

C(`, δ)← C(`0, δ`)

Figure 2.2: Instrumented evaluator I, imperative style.

as a flow. The instrumented interpreter works by accumulating a set of flows asthey occur during evaluation.

Notice that this evaluator does not return values—it writes them into the cache: ifthe expression t` evaluates in the contour δ to v, then C(`, δ) is assigned v. Whenthe value of a subexpression is needed, as in the application case, the subexpres-sion is first interpreted (causing its value to be written in the cache) and subse-quently retrieved from the C cache. When the value of a variable is needed, it isretrieved from the r cache, using the contour environment to get the appropriatebinding.

In other words, C is playing the role of a global return mechanism, while r isplaying the role of a global environment.

Although the evaluator is mutating the cache, each location is written into justonce. A straight-forward induction proof shows that the current label togetherwith the current contour—which constitute the cache address that will be writteninto—forms a unique string.

Returning to the earlier example, the cache constructed by

IJ((λf.(f(f True)1)2)(λy.False))3K•ε

includes the following entries:

r(f, 3) = λy.False

15


r(y, 321) = True

r(y, 32) = False

C(1, 32) = λy.False

C(3, ε) = False

The evaluator can be written in a functional style by threading the cache throughthe computation as seen in Figure 2.3.

I : Exp× Env ×∆×Cache⇀ Cache

IJx`Kρδ C, r = C[(`, δ) 7→ r(x, ρ(x))], rIJ(λx.e)`Kρδ C, r = C[(`, δ) 7→ 〈λx.e, ρ′〉], r

where ρ′ = ρ� fv(λx.e)IJ(t`1t`2)`Kρδ C, r = let C1, r1 = IJt`1Kδρ C, r in

let C2, r2 = IJt`2Kδρ C1, r1 inlet 〈λx.t`0 , ρ′〉 = C2(`1, δ) inlet r3 = r2[(x, δ`) 7→ C3(`2, δ)] inlet C3, r4 = IJt`0Kδ`ρ′[x7→δ`] C2, r3 inlet C4 = C3[(`, δ) 7→ C3(`0, δ`)] inC4, r4

Figure 2.3: Instrumented evaluator I, functional style.

In a more declarative style, we can write a specification of acceptable caches; acache is acceptable iff it records at least all of the flows which occur during instru-mented evaluation. The smallest cache satisfying this acceptability relation is theone that is computed by the above interpreter, clearly. The acceptability relationis given in Figure 2.4. It is same cache acceptability relation can be obtained fromthat given by Nielson et al. (1999, Table 3.10, page 192) for kCFA by letting kbe arbitrarily large. (Looking ahead, the idea of kCFA is that the evaluator willbegin to lose information and approximate evaluation after a contour has reacheda length of k. If k is sufficiently large, approximation never occurs. So the accept-ability relation of Figure 2.4 can also be seen as the specification of “∞CFA”. Forany program that terminates, there is a k such that performing kCFA results in acache meeting the specification of Figure 2.4. In other words, for any programthat halts, there is a k such that kCFA runs it.)

16


C, r |=ρδ x

` iff C(`, δ) = r(x, ρ(x))C, r |=ρ

δ (λx.e)` iff C(`, δ) = 〈λx.e, ρ′〉where ρ′ = ce� fv(λx.e)

C, r |=ρδ (t`1 t`2)` iff C |=ρ

δ t`1 ∧ C |=ρ

δ t`2 ∧

let 〈λx.t`0 , ρ′〉 = C(`1, δ) inr(x, δ`) = C(`2, δ) ∧C, r |=ρ′[x 7→δ`]

δ` t`0 ∧C(`, δ) = C(`0, δ`)

Figure 2.4: Exact cache acceptability, or Instrumented evaluator I, declarativestyle.

There may be a multitude of acceptable analyses for a given program, so cachesare partially ordered by:

C v C′ iff ∀`, δ : C(`, δ) = v ⇒ C′(`, δ) = vr v r′ iff ∀x, δ : r(x, δ) = v ⇒ r′(x, δ) = v

Generally, we are concerned only with the least such caches with respect to thedomain of variables and labels found in the given program of interest.

Clearly, because constructing such a cache is equivalent to evaluating a program,it is not effectively computable.

All of the flow analyses considered in this dissertation can be thought of as an ab-straction (in the sense of being a computable approximation) to this instrumentedinterpreter, which not only evaluates a program, but records a history of flows.

2.3 Abstracted Interpretation

Computing a complete program trace can produce an arbitrarily large cache. Oneway to regain decidability is to bound the size of the cache. This is achieved inkCFA by bounding the length of contours to k labels.

If during the course of evaluation, or more appropriately analysis, the contour isextended to exceed k labels, the analyzer will truncate the string, keeping the k

17


most recent labels.

But now that the cache size is bounded, a sufficiently large computation will ex-haust the cache. Due to truncation, the uniqueness of cache locations no longerholds and there will come a point when a result needs to be written into a locationthat is already occupied with a different value. If the analyzer were to simply over-write the value already in that location, the analysis would be unsound. Insteadthe analyzer must consider both values as flowing out of this point.

This in turn can lead to further approximation. Suppose a function applicationhas two values given for flow analysis of the operator subterm and another twovalues given for the operand. The analyzer must consider the application of eachfunction to each argument.

kCFA is a safe, computable approximation to this instrumented interpreter; it is akind of abstract interpretation (Cousot and Cousot 1977; Jones and Nielson 1995;Nielson et al. 1999). Rather than constructing an exact cache C, r, it constructs anabstract cache C, r:

C : Lab×∆→ Val

r : Var×∆→ Val

Cache = (Lab×∆→ Val)× (Var×∆→ Val)

which maps labels and variables, not to values, but to sets of values—abstractvalues:

v ∈ Val = P(Term× Env) abstract values.

Approximation arises from contours being bounded at length k. If during thecourse of instrumented evaluation, the length of the contour would exceed lengthk, then the kCFA abstract interpreter will truncate it to length k. In other words,only a partial description of the context can be given, which results in ambiguity.A subexpression may evaluate to two distinct values, but within contexts which areonly distinguished by k+1 labels. Questions about which value the subexpressionevaluates to can only supply k labels, so the answer must be both, according to asound approximation.

When applying a function, there is now a set of possible closures that flow intothe operator position. Likewise, there can be a multiplicity of arguments. What isthe interpreter to do? The abstract interpreter must apply all possible closures toall possible arguments.

18


The abstract interpreter A, the imprecise analog of I, is given in Figure 2.5 usingthe concise imperative style. We write C(`, δ)← v (or r(x, δ)← v) to indicate an

Ak : Exp× Env ×∆→ Unit

AkJx`Kρδ = C(`, δ)← r(x, ρ(x))

AkJ(λx.e)`Kρδ = C(`, δ)← {〈λx.e, ρ′〉}where ρ′ = ρ� fv(λx.e)

AkJ(t`1t`2)`Kρδ = AkJt`1Kρδ ;AkJt`2Kρδ ;

for each 〈λx.t`0 , ρ′〉 in C(`1, δ) dor(x, dδèk)← C(`2, δ);

AkJt`0Kρ′[x 7→dδèk]dδèk ;

C(`, δ)← C(`0, dδèk)

Figure 2.5: Abstract evaluator A, imperative style.

updated cache where `, δ (resp., x, δ) maps to C(`, δ) ∪ v (resp., r(`, δ) ∪ v). Thenotation dδek denotes δ truncated to the rightmost (i.e., most recent) k labels.

There are many ways the concise imperative abstract evaluator can be written ina more verbose functional style, and this style will be useful for proofs in thefollowing sections.

Compared to the exact evaluator, contours similarly distinguish evaluation withincontexts described by as many as k application sites: beyond this, the distinction isblurred. The imprecision of the analysis requires thatA be iterated until the cachereaches a fixed point, but care must taken to avoid looping in an iteration since asingle iteration of AkJeKρδ may in turn make a recursive call to AkJeKρδ under thesame contour and environment. This care is the algorithmic analog of appealing tothe co-inductive hypothesis in judging an analysis acceptable (described below).

We interpret C(`, δ) = {v, . . .} as saying, “the expression labeled ` may evaluateto v in the context described by δ,” and r(x, δ) = v as “the variable x is may bebound to v in the context described by δ.” Conversely, we say “v flows to theexpression labelled ` into the context described by δ” and each {v, . . .} “flowsout of the expression labelled ` in the context described by δ,” and “v flows tothe binding of x in the context described by δ,” respectively. We refer to a fact

19


Ak : Exp× Env ×∆× Cache→ Cache

AkJx`Kρδ C, r = C[(`, δ) 7→ r(x, ρ(x))], r

AkJ(λx.e)`Kρδ C, r = C[(`, δ) 7→ {〈λx.e, ρ′〉}], rwhere ρ′ = ρ� fv(λx.e)

AkJ(t`1 t`2)`Kρδ C, r = C3[(`, δ) 7→ C3(`0, δ′)], r3, where

δ′ = dδèkC1, r1 = AkJt`1Kρδ C, rC2, r2 = AkJt`2Kρδ C1, r1C3, r3 =⊔C2(`,δ)

〈λx.t`0 ,ρ′〉

(AkJt`0Kρ

′[x 7→δ′]δ′ C2, r2[(x, δ′) 7→ C2(`2, δ)]

)Figure 2.6: Abstract evaluator A, functional style.

such as, C(`, δ) 3 v or r(x, δ) 3 v, as a flow. The abstract interpreter worksby accumulating a set of flows as they occur during abstract interpretation untilreaching a fixed point. Although this overloads the terminology used in describingthe instrumented interpreter, the notions are compatible and the setting shouldmake it clear which sense is intended.

An acceptable k-level control flow analysis for an expression e is written C, r |=ρδ

e, which states that C, r is an acceptable analysis of e in the context of the currentenvironment ρ and current contour δ (for the top level analysis of a program, thesewill both be empty).

Just as done in the previous section, we can write a specification of acceptablecaches rather than an algorithm that computes. The resulting specification givenin Figure 2.7 is what is found, for example, in Nielson et al. (1999).

There may be a multitude of acceptable analyses for a given program, so cachesare partially ordered by:

C v C′ iff ∀`, δ : C(`, δ) = v ⇒ v ⊆ C′(`, δ)r v r′ iff ∀x, δ : r(x, δ) = v ⇒ v ⊆ r′(x, δ)

Generally, we are concerned only with the least such caches with respect to the

20


C, r |=ρδ x

` iff r(x, ρ(x)) ⊆ C(`, δ)

C, r |=ρδ (λx.e)` iff 〈λx.e, ρ′〉 ∈ C(`, δ)

where ρ′ = ce� fv(λx.e)

C, r |=ρδ (t`1 t`2)` iff C, r |=ρ

δ t`1 ∧ C, r |=ρ

δ t`2∧

∀〈λx.t`0 , ρ′〉 ∈ C(`1, δ) :

C(`2, δ) ⊆ r(x, dδèk)∧C, r |=ce′[x7→dδèk]

dδèk t`0∧C(`0, dδèk) ⊆ C(`, δ)

Figure 2.7: Abstract cache acceptability, or Abstract evaluator A, declarativestyle.

domain of variables and labels found in the given program of interest.

By bounding the contour length, the inductive proof that (`, δ) was unique forany write into the cache was invalidated. Similarly, induction can no longerbe relied upon for verification of acceptability. It may be the case that provingC, r |=ρ

δ t` obligates proofs of other propositions, which in turn rely upon verifica-

tion of C, r |=ρδ t

`. Thus the acceptability relation is defined co-inductively, givenby the greatest fixed point of the functional defined according to the followingclauses of Figure 2.7. Proofs by co-induction would allow this later obligation tobe dismissed by the co-inductive hypothesis.

Fine print: To be precise, we take as our starting point uniform kCFA ratherthan a kCFA in which,

Cache = (Lab× Env→ Val)× (Var× Env→ Val)

The differences are immaterial for our purposes. See Nielson et al. (1999) fordetails and a discussion on the use of coinduction in specifying static analyses.

Having established the foundations of evaluation and analysis, we now turn to thefoundations of our tools and techniques employed in the investigation of programanalysis.

21


2.4 Computational Complexity

2.4.1 Why a Complexity Investigation?

Static analysis can be understood as a “technique for computing conservative ap-proximations of solution for undecidable problems.”3 Complexity characteriza-tions therefore offer a natural refinement of that understanding.

A fundamental question we need to be able to answer is this: what can be deducedabout a long-running program with a time-bounded analyzer? When we staticallyanalyze exponential-time programs with a polynomial-time method, there shouldbe a analytic bound on what we can learn at compile-time: a theorem delineatinghow exponential time is being viewed through the compressed, myopic lens ofpolynomial time computation.

We are motivated as well by yardsticks such as Shannon’s theorem from informa-tion theory (Shannon 1948): specify a bandwidth for communication and an errorrate, and Shannon’s results give bounds on the channel capacity. We too have es-sential measures: the time complexity of our analysis, the asymptotic differentialbetween that bound and the time bound of the program we are analyzing. Thereought to be a fundamental result about what information can be yielded as a func-tion of that differential. At one end, if the program and analyzer take the sametime, the analyzer can just run the program to find out everything. At the otherend, if the analyzer does no work (or a constant amount of work), nothing can belearned. Analytically speaking, what is in between?

In the closely related area of pointer analysis, computational complexity has playeda prominent role in the development and evaluation of analyses.4 It was the start-ing point for the widely influential Landi and Ryder (1992), according to the au-thors’ retrospective (2004).

The theory of computational complexity has proved to be a fruitful tool in relat-ing seemingly disparate computational problems. Through notions of logspace

3Quoted from Michael Schwartzbach’s 2009 Static Analysis course description from Universityof Aarhus (http://www.brics.dk/∼mis/static.html/, accessed June 3, 2009). The same sentiment isexpressed in Patrick Cousot’s 2005 MIT Abstract Interpretation lecture notes on undecidability,complexity, automatic abstract termination proofs by semidefinite programming (http://web.mit.edu/16.399/www/).

4See section 6.7 for details.

22

http://www.brics.dk/~mis/static.html/

http://web.mit.edu/16.399/www/

http://web.mit.edu/16.399/www/


reductions5 between problems, what may have appeared to be two totally unre-lated problems can be shown to be, in fact, so closely related that a method forefficiently computing solutions to one can be used as a method for efficiently com-puting the other, and vice versa. For example, at first glance, 0CFA and circuitevaluation have little to do with each other. Yet, as shown in this dissertation, thetwo problems are intimately related; they are both complete for PTIME.

There are two fundamental relations a problem can have to a complexity class.The problem can be included in the complexity class, meaning the problem isno harder than the hardest problems in the class. Or, the problem can be a hardproblem within the class, meaning that no other problem in the class is harder thanthis one. When a problem is both included and hard for a given class, it said tobe complete for that class; it is as hard as the hardest problems in the class, but noharder.

Inclusion results establish feasibility of analysis—it tells us analysis can be per-formed within some upper-bound on resources. These results are proven by con-structing efficient and correct program analyzers, either by solving the analysisproblem directly or reducing it to another problem with a known inclusion.

Hardness results, on the other hand, establish the minimum resource requirementsto perform analysis in general. They can be viewed as lower-bounds on the dif-ficulty of analysis, telling us, for example, when no amount of cleverness in al-gorithm design will improve on the efficiency of performing analysis. So whileinclusion results have an existential form: “there exists an algorithm such that itoperates within these bounded resources,” hardness results have a universal form:“for all algorithms computing the analysis, at least these resources can be con-sumed.”

Whereas inclusion results require clever algorithmic insights applied to a programanalyzer, hardness results require clever exploitation of the analysis to performcomputational work.

Lower bounds are proved by giving reductions—efficient compilers—for trans-forming instances of some problem that is known to be hard for a class, (e.g.circuit evaluation and PTIME) into instances of a flow analysis problem. Such areduction to a flow analysis problem establishes a lower bound on the complexity

5Logspace reductions are essentially memory efficient translations between instances of problems.The PL-theorist may be most comfortable thinking of these reductions as space-efficient compil-ers.

23


of flow analysis: solving the flow problem must be at least as hard as solving theoriginal problem, which is known to be of the hardest in the class.

The aim, then, is to solve hard problems by make principled use of the analysis.From a programming language perspective, the analyzer can be regarded as anevaluator of a language, albeit a language with implicit resource bounds and a(sometimes) non-standard computational model. Lower bounds can be provedby writing computationally intensive programs in this language. That is, provinglower bounds is an exercise in clever hacking in the language of analysis.

For flow analysis, inclusion results are largely known. Simple algorithmic analysisapplied to the program analyzer is often sufficient to establish an upper bound.

Much work in the literature on flow analysis has been concerned with findingmore and more efficient ways to compute various program analyses. But whilegreat effort has been expended in this direction, there is little work addressing thefundamental limits of this endeavour. Lower-bounds tell us to what extent this ispossible.

This investigation also provides insight into a more general subject: the complex-ity of computing via abstract interpretation. It stands to reason that as the compu-tational domain becomes more refined, so too should computational complexity.In this instance, the domain is the size of the abstract cache C and the values(namely, closures) that can be stored in the cache. As the cache size and num-ber of closures increase6, so too should the complexity of computation. From atheoretical perspective, we would like to understand better the trade-offs betweenthese various parameters.

Viewed from another perspective, hardness results can be seen as a characteriza-tion of the expressiveness of an analysis; it is a measure of the work an analysisis capable of doing. The complexity and expressivity of an analysis are two sidesof the same coin and analyses can be compared and characterized by the classof computations each captures. In their definitive study, Nielson et al. (1999) re-mark, “Program analysis is still far from being able to precisely relate ingredientsof different approaches to one another,” but we can use computational complexitytheory as an effective tool in relating analyses. Moreover, insights gleaned fromthis understanding of analysis can inform future analysis design. To develop richanalyses, we should expect larger and larger classes to be captured. In short: com-

6Observe that since closure environments map free variables to contours, the number of closuresincreases when the contour length k is increased.

24


putational complexity is a means to both organize and extend the universe of staticanalyses.

Other research has shown a correspondence between 0CFA and certain type sys-tems (Palsberg and O’Keefe 1995; Heintze 1995) and a further connection hasbeen made between intersection typing and kCFA (Mossin 1997b; Palsberg andPavlopoulou 2001). Work has also been done on relating the various flavorsof control flow analysis, such as 0CFA, kCFA, polymorphic splitting, and uni-form kCFA (Nielson and Nielson 1997). Moreover, control flow analysis can becomputed under a number of different guises such as set-based analysis (Heintze1994), closure analysis (Sestoft 1988, 1989), abstract interpretation (Shivers 1991;Tang and Jouvelot 1994; Might and Shivers 2006a; Might 2007; Midtgaard andJensen 2008, 2009), and type and effect systems (Faxen 1995; Heintze 1995;Faxen 1997; Banerjee 1997).

We believe a useful taxonomy of these and other static analyses can be derivedby investigating their computational complexity. Results on the complexity ofstatic analyses are way of understanding when two seemingly different programanalyses are in fact computing the same thing.

2.4.2 Complexity Classes

In this section, we review some basic definitions about complexity classes anddefine the flow analysis problem.

A complexity class is specified by a model of computation, a mode of computa-tion (e.g. deterministic, non-deterministic), the designation of a unit of work—aresource used up by computation (e.g. time, space), and finally, a function f thatbounds the use of this resource. The complexity class is defined as the set of alllanguages decided by some Turing machine M that for any input x operates in thegiven mode within the bounds on available resources, at most f(|x|) units of work(Papadimitriou 1994, page 139).

Turing machines are used as the model of computation, in both deterministic andnon-deterministic mode. Recall the formal definition of a Turing machine: a 7-tuple

〈Q,Σ,Γ, δ, q0, qa, qr〉

where Q, Σ, and Γ are finite sets, Q is the set of machine states (and {q0, qa, qr} ⊆

25


Q), Σ is the input alphabet, and Γ is the tape alphabet, where Σ ⊆ Γ. For adeterministic machine, the transition function, δ, is a partial function that mapsthe current machine state and tape contents under the head position to the nextmachine state, a symbol to write on the tape under the head, and left or right shiftoperation for moving the head. For a non-deterministic machine, the transitionfunction is actually a relation and may map each machine configuration to multiplesuccessor configurations. The states q0, qa, and qr are the machine’s initial, accept,and reject states, respectively. Transitions consume one unit of time and spaceconsumption is measured by the amount of tape used.

Definition 1. Let f : N → N . We say that machine M operates within time f(n)if, for any input string x, the time required by M on x is at most f(|x|) where |x|denotes the length of string x. Function f(n) is a time bound for M .

Let g : N → N . We say that machine M operates within space g(n) if, for anyinput string x, the space required for the work tape of M on x is at most g(|x|).Function g(n) is a space bound for M .

Space bounds do not take into consideration the amount of space needed to repre-sent the input or output of a machine, but only its working memory. To this end,one can consider Turing machines with three tapes: an input, output and worktape. (Such machines can be simulated by single tape Turing machines with aninconsequential loss of efficiency). The input tape is read-only and contains theinput string. The work tape is initially empty and can be read from and writtento. The output tape, where the result of computation is written, is initially emptyand is write only. A space bound characterizes the size of the work only. SeePapadimitriou (1994, Sections 2.3–5) or Garey and Johnson (1979, Section 7.5)for further details.

A complexity class is a set of languages representing decision problems that canbe decided within some specified bound on the resources used, typically time andspace. Suppose the decision problem can be decided by a deterministic Turingmachine operating in time (space) f(n), we say the problem is in DTIME(f(n))(DSPACE(f(n))); likewise, if a problem can be decided by a non-deterministicTuring machine operating in time f(n), we say the problem is in NTIME(f(n)).

26


We make use of the following standard complexity classes:

LOGSPACE =⋃j>0 DSPACE(j log n)

⊆ PTIME =⋃j>0 DTIME(nj)

⊆ NPTIME =⋃j>0 NTIME(nj)

⊆ EXPTIME =⋃j>0 DTIME(2n

j)

In addition to the above inequalities, it is known that PTIME ⊂ EXPTIME.

What is the difficulty of computing within this hierarchy? What are the sourcesof approximation that render such analysis tractable? We examine these questionsin relation to flow analysis problems, which are decision problems, computationalproblems that require either a “yes” or “no” answer, and therefore are insensitiveto output size (it is just one bit).

The flow analysis decision problem we examine is the following:

Flow analysis decision problem: Given an expression e, an abstract value v, anda pair (`, δ), does v flow into (`, δ) by this flow analysis?

2.5 Proving Lower Bounds: The Art of Exploitation

Program exploitation—a staple of hacking—is simply a clever way of making aprogram do what you want it to do, even if it was designed to prevent that action(Erickson 2008, page 115). This is precisely the idea in proving lower bounds,too.

The program to be exploited, in this setting, is the static analyzer. What we wouldlike to do varies, but generally we want to exploit analysis to solve various com-putationally difficult classes of problems. In some cases, what we want to do isevaluate, rather than approximate, the program being analyzed. In this sense, wetruly subvert the analyzer by using it to carry out that which it was designed toavoid (to discover without actually running (Muchnick and Jones 1981, page xv)).

The approach of exploiting analysis for computation manifests itself in two waysin this dissertation:

27


1. Subverting abstraction

The first stems from a observation that perhaps the languages of abstractand concrete interpretation intersect. That is, abstract interpretation makesapproximations compared to concrete interpretation, but perhaps there isa subset of programs on which no approximation is made by analysis. Forthis class of programs, abstract and concrete interpretation are synonymous.Such a language certainly exists for all of the flow analyses examined inthis dissertation. We conjecture that in general, for every useful abstractinterpretation, there is a subset of the analyzed language for which abstractand concrete interpretation coincide. By identifying this class of programs,lower bounds can be proved by programming within the subset.

One of the fundamental ideas of computer science is that “we can regard al-most any program as the evaluator for some language” (Abelson and Suss-man 1996, page 360). So it is natural to ask of any algorithm, what is thelanguage being evaluated? The question is particularly relevant when askedof an abstract evaluator. We can gain insight into an analysis by comparingthe language of the abstract evaluator to the language of the concrete evalu-ator.

So a program analysis itself can be viewed as a kind of programming lan-guage, and an analyzer as a kind of evaluator. Because of the requisitedecidability of analysis, these languages will come with implicit bounds oncomputational resources—if the analysis is decidable, these languages can-not be Turing-complete. But lower bounds can be proved by clever hackingwithin the unconventional language of analysis.

This approach is the subject of chapter 3.

2. Harnessing re-evaluation

The second way analysis can be exploited is to identify the sources of ap-proximation in the analysis and instead of avoiding them, (turning the ab-stract into the concrete as above), harness them for combinatorial power. Inthis approach, lower bounds can be proved by programming the language ofthe analysis in a way that has little to do with programming in the languageof concrete interpretation.

Researchers have made empirical observations that computing a more pre-cise analysis is often cheaper than performing a less precise one. Theless precise analysis “yields coarser approximations, and thus induces more

28


merging. More merging leads to more propagation, which in turn leadsto more reevaluation” (Wright and Jagannathan 1998). Might and Shivers(2006b) make a similar observation: “imprecision reinforces itself during aflow analysis through an ever-worsening feedback loop.” For the purposesof proving lower bounds, we are able to harness this re-evaluation as a com-putation engine.

This approach is the subject of chapter 5.

29

Chapter 3

Monovariant Analysis and PTIME

The monovariant form of flow analysis defined over the pure λ-calculus has emergedas a fundamental notion of flow analysis for higher-order languages, and someform of flow analysis is used in most analyses for higher-order languages (Heintzeand McAllester 1997a).

In this chapter, we examine several of the most well-known variations of mono-variant flow analysis: Shivers’ 0CFA (1988), Henglein’s simple closure analysis(1992), Heintze and McAllester’s subtransitive flow analysis (1997a), Ashley andDybvig’s sub-0CFA (1998), Mossin’s single source/use analysis (1998), and oth-ers.

In each case, evaluation and analysis are proved equivalent for the class of linearprograms and a precise characterization of the computational complexity of theanalysis, namely PTIME-completeness, is given.

3.1 The Approximation of Monovariance

To ensure tractability of any static analysis, there has to be an approximation ofsomething, where information is deliberately lost in the service of providing whatis left in a reasonable amount of time. A good example of what is lost duringmonovariant static analysis is that the information gathered for each occurrenceof a bound variable is merged. When variable f occurs twice in function position

31

CHAPTER 3. MONOVARIANT ANALYSIS AND PTIME

with two different arguments,

(f v1) · · · (f v2)

a monovariant flow analysis will blur which copy of the function is applied towhich argument. If a function λz.e flows into f in this example, the analysistreats occurrences of z in e as bound to both v1 and v2.

Shivers’ 0CFA is among the most well-known forms of monovariant flow anal-ysis; however, the best known algorithm for 0CFA requires nearly cubic time inproportion to the size of the analyzed program.

It is natural to wonder whether it is possible to do better, avoiding this bottle-neck, either by improving the 0CFA algorithm in some clever way or by furtherapproximation for the sake of faster computation.

Consequently, several analyses have been designed to approximate 0CFA by trad-ing precision for faster computation. Henglein’s simple closure analysis, for ex-ample, forfeits the notion of directionality in flows. Returning to the earlier exam-ple,

f(λx.e′) · · · f(λy.e′′)

simple closure analysis, like 0CFA, will blur λx.e′ and λy.e′′ as arguments to f ,causing z to be bound to both. But unlike 0CFA, a bidirectional analysis suchas simple closure analysis will identify two λ-terms with each other. That is,because both are arguments to the same function, by the bi-directionality of theflows, λx.e′ may flow out of λy.e′′ and vice versa.

Because of this further curtailing of information, simple closure analysis enjoysan “almost linear” time algorithm. But in making trade-offs between precisionand complexity, what has been given up and what has been gained? Where dothese analyses differ and where do they coincide?

We identify a core language—the linear λ-calculus—where 0CFA, simple closureanalysis, and many other known approximations or restrictions to 0CFA are ren-dered identical. Moreover, for this core language, analysis corresponds with (in-strumented) evaluation. Because analysis faithfully captures evaluation, and be-cause the linear λ-calculus is complete for PTIME, we derive PTIME-completenessresults for all of these analyses.

Proof of this lower bound relies on the insight that linearity of programs subvertsthe approximation of analysis and renders it equivalent to evaluation. We establish

32


a correspondence between Henglein’s simple closure analysis and evaluation forlinear terms. In doing so, we derive sufficient conditions effectively characteriz-ing not only simple closure analysis, but many known flow analyses computablein less than cubic time, such as Ashley and Dybvig’s sub-0CFA, Heintze andMcAllester’s subtransitive flow analysis, and Mossin’s single source/use analysis.

By using a nonstandard, symmetric implementation of Boolean logic within thelinear lambda calculus, it is possible to simulate circuits at analysis-time, and asa consequence, we prove that all of the above analyses are complete for PTIME.Any sub-polynomial algorithm for these problems would require (unlikely) break-through results in complexity, such as PTIME = LOGSPACE.

We may continue to wonder whether it is possible to do better, either by im-proving the 0CFA algorithm in some clever way or by further approximation forfaster computation. However these theorems demonstrate the limits of both av-enues. 0CFA is inherently sequential, and so is any algorithm for it, no matterhow clever. Designing a provably efficient parallel algorithm for 0CFA is as hardas parallelizing all polynomial time computations. On the other hand, furtherapproximations, such as simple closure analysis and most other variants of mono-variant flow analysis, make no approximation on a linear program. This meansthey too are inherently sequential and no easier to parallelize.

3.2 0CFA

Something interesting happens when k = 0. Notice in the application rule of thekCFA abstract evaluator of Figure 2.5 that environments are extended as ρ[x 7→dδèk]. When k = 0, dδè0 = ε. All contour environments map to the empty con-tour, and therefore carry no contextual information. As such, 0CFA is a “mono-variant” analysis, analogous to simple-type inference, which is a monovariant typeanalysis.

Since there is only one constant environment (the “everywhere ε” environment),environments of section 2.3 can be eliminated from the analysis altogether andthe cache no longer needs a contour argument. Likewise, the set of abstract valuescollapses from P(Term× Env) into P(Term).

The result of 0CFA is an abstract cache that maps each program point (i.e., label)to a set of lambda abstractions which potentially flow into this program point at

33


run-time:

C : Lab→ P(Term)r : Var→ P(Term)

Cache = (Lab→ P(Term))× (Var→ P(Term))

Caches are extended using the notation C[` 7→ s], and we write C[` 7→+ s] tomean C[` 7→ (s∪ C(`))]. It is convenient to sometimes think of caches as mutabletables (as we do in the algorithm below), so we abuse syntax, letting this notationmean both functional extension and destructive update. It should be clear fromcontext which is implied.

The Analysis: We present the specification of the analysis here in the style ofNielson et al. (1999). Each subexpression is identified with a unique superscriptlabel `, which marks that program point; C(`) stores all possible values flowingto point `, r(x) stores all possible values flowing to the definition site of x. Anacceptable 0CFA analysis for an expression e is written C, r |= e and derivedaccording to the scheme given in Figure 3.1.

C, r |= x` iff r(x) ⊆ C(`)

C, r |= (λx.e)` iff λx.e ∈ C(`)

C, r |= (t`1 t`2)` iff C, r |= t`1 ∧ C, r |= t`2 ∧∀λx.t`0 ∈ C(`1) :

C(`2) ⊆ r(x) ∧C, r |= t`0 ∧C(`0) ⊆ C(`)

Figure 3.1: 0CFA abstract cache acceptability.

The |= relation needs to be coinductively defined since verifying a judgmentC, r |= e may obligate verification of C, r |= e′ which in turn may require ver-ification of C, r |= e. The above specification of acceptability, when read as atable, defines a functional, which is monotonic, has a fixed point, and |= is de-

34


fined coinductively as the greatest fixed point of this functional.1

Writing C, r |= t` means “the abstract cache contains all the flow information forprogram fragment t at program point `.” The goal is to determine the least cachesolving these constraints to obtain the most precise analysis. Caches are partiallyordered with respect to the program of interest:

C v C′ iff ∀` : C(`) ⊆ C′(`)r v r′ iff ∀x : r(x) ⊆ r′(x)

These constraints can be thought of as an abstract evaluator— C, r |= t` simplymeans evaluate t`, which serves only to update an (initially empty) cache.

A0Jx`K = C(`)← r(x)

A0J(λx.e)`K = C(`)← {λx.e}A0J(t`1 t`2)`K = A0Jt`1K; A0Jt`2K;

for each λx.t`0 in C(`1) dor(x)← C(`2);A0Jt`0K;

C(`)← C(`0)

Figure 3.2: Abstract evaluator A0 for 0CFA, imperative style.

The abstract evaluatorA0J·K is iterated until the finite cache reaches a fixed point.

Fine Print: A single iteration ofA0JeK may in turn make a recursive callA0JeKwith no change in the cache, so care must be taken to avoid looping. This amountsto appealing to the coinductive hypothesis C, r |= e in verifying C, r |= e. How-ever, we consider this inessential detail, and it can safely be ignored for the pur-poses of obtaining our main results in which this behavior is never triggered.

Since the cache size is polynomial in the program size, so is the running time, asthe cache is monotonic—values are put in, but never taken out. Thus the analysisand any decision problems answered by the analysis are clearly computable withinpolynomial time.1See Nielson et al. (1999) for details and a thorough discussion of coinduction in specifying staticanalyses.

35


Lemma 1. The control flow problem for 0CFA is contained in PTIME.

Proof. 0CFA computes a binary relation over a fixed structure. The computationof the relation is monotone: it begins as empty and is added to incrementally.Because the structure is finite, a fixed point must be reached by this incrementalcomputation. The binary relation can be at most polynomial in size, and eachincrement is computed in polynomial time.

An Example: Consider the following program, which we will return to discussfurther in subsequent analyses:

((λf.((f 1f 2)3(λy.y4)5)6)7(λx.x8)9)10

The least 0CFA is given by the following cache:

C(1) = {λx} C(6) = {λx, λy}C(2) = {λx} C(7) = {λf}C(3) = {λx, λy} C(8) = {λx, λy}C(4) = {λy} C(9) = {λx}C(5) = {λy} C(10) = {λx, λy}

r(f) = {λx}r(x) = {λx, λy}r(y) = {λy}

where we write λx as shorthand for λx.x8, etc.

3.3 Henglein’s Simple Closure Analysis

Simple closure analysis follows from an observation by Henglein some 15 yearsago “in an influential though not often credited technical report” (Midtgaard 2007,page 4): he noted that the standard control flow analysis can be computed indramatically less time by changing the specification of flow constraints to useequality rather than containment (Henglein 1992). The analysis bears a strongresemblance to simple-type inference—analysis can be performed by emitting asystem of equality constraints and then solving them using unification, which canbe computed in almost linear time with a union-find data structure.

36


Consider a program with both (f x) and (f y) as subexpressions. Under 0CFA,whatever flows into x and y will also flow into the formal parameter of all abstrac-tions flowing into f , but it is not necessarily true that whatever flows into x alsoflows into y and vice versa. However, under simple closure analysis, this is thecase. For this reason, flows in simple closure analysis are said to be bidirectional.

The Analysis: The specification of the analysis is given in Figure 3.3.

C, r |= x` iff r(x) = C(`)

C, r |= (λx.e)` iff λx.e ∈ C(`)

C, r |= (t`1 t`2)` iff C, r |= t`1 ∧ C, r |= t`2 ∧∀λx.t`0 ∈ C(`1) :

C(`2) = r(x) ∧C, r |= t`0 ∧C(`0) = C(`)

Figure 3.3: Simple closure analysis abstract cache acceptability.

The Algorithm: We write C[`↔ `′] to mean C[` 7→+ C(`′)][`′ 7→+ C(`)].

A0Jx`K = C(`)↔ r(x)

A0J(λx.e)`K = C(`)← {λx.e}A0J(t`11 t

`22 )`K = A0Jt`11 K; A0Jt`22 K;

for each λx.t`00 in C(`1) dor(x)↔ C(`2);

A0Jt`00 K;

C(`)↔ C(`0)

The abstract evaluator A0J·K is iterated until a fixed point is reached.2 By similarreasoning to that given for 0CFA, simple closure analysis is clearly computablewithin polynomial time.

Lemma 2. The control flow problem for simple closure analysis is contained inPTIME.2The fine print of section 3.2 applies as well.

37


An Example: Recall the example program of the previous section:

((λf.((f 1f 2)3(λy.y4)5)6)7(λx.x8)9)10

Notice that λx.x is applied to itself and then to λy.y, so x will be bound to bothλx.x and λy.y, which induces an equality between these two terms. Consequently,everywhere that 0CFA was able to deduce a flow set of {λx} or {λy} will bereplaced by {λx, λy} under a simple closure analysis. The least simple closureanalysis is given by the following cache (new flows are underlined):

C(1) = {λx, λy} C(6) = {λx, λy}C(2) = {λx, λy} C(7) = {λf}C(3) = {λx, λy} C(8) = {λx, λy}C(4) = {λy, λx} C(9) = {λx, λy}C(5) = {λy, λx} C(10) = {λx, λy}

r(f) = {λx, λy}r(x) = {λx, λy}r(y) = {λy, λx}

3.4 Linearity: Analysis is Evaluation

It is straightforward to observe that in a linear λ-term, each abstraction λx.e canbe applied to at most one argument, and hence the abstracted value can be boundto at most one argument.3 Generalizing this observation, analysis of a linear λ-term coincides exactly with its evaluation. So not only are the analyses equivalenton linear terms, but they are also synonymous with evaluation.

A natural and expressive class of such linear terms are the ones which implementBoolean logic. When analyzing the coding of a Boolean circuit and its inputs,the Boolean output will flow to a predetermined place in the (abstract) cache.By placing that value in an appropriate context, we construct an instance of thecontrol flow problem: a function f flows to a call site a iff the Boolean output isTrue.

Since the circuit value problem (Ladner 1975), which is complete for PTIME,can be reduced to an instance of the 0CFA control flow problem, we concludethis control flow problem is PTIME-hard. Further, as 0CFA can be computed inpolynomial time, the control flow problem for 0CFA is PTIME-complete.3Note that this observation is clearly untrue for the nonlinear λ-term (λf.f(a(fb)))(λx.x), as xis bound to b, and also to ab.

38


E ′ : Exp× Env ⇀ Val

E ′Jx`K[x 7→ v] = vE ′J(λx.e)`Kρ = 〈λx.e, ρ〉E ′J(e1 e2)`Kρ = let 〈λx.e0, ρ

′〉 = E ′Je1Kρ� fv(e1) inlet v = E ′Je2Kρ� fv(e2) inE ′Je0Kρ′[x 7→ v]

Figure 3.4: Evaluator E ′.

One way to realize the computational potency of a static analysis is to subvertthis loss of information, making the analysis an exact computational tool. Lowerbounds on the expressiveness of an analysis thus become exercises in hacking,armed with this newfound tool. Clearly the more approximate the analysis, theless we have to work with, computationally speaking, and the more we have todo to undermine the approximation. But a fundamental technique has emerged inunderstanding expressivity in static analysis—linearity.

In this section, we show that when the program is linear—every bound variableoccurs exactly once—analysis and evaluation are synonymous.

First, we start by considering an alternative evaluator, given in Figure 3.4, whichis slightly modified from the one given in Figure 2.1. Notice that this evalu-ator “tightens” the environment in the case of an application, thus maintainingthroughout evaluation that the domain of the environment is exactly the set of freevariables in the expression. When evaluating a variable occurrence, there is onlyone mapping in the environment: the binding for this variable. Likewise, whenconstructing a closure, the environment does not need to be restricted: it alreadyis.

This alternative evaluator E ′ will be useful in reasoning about linear programs,but it should be clear that it is equivalent to the original, standard evaluator E ofFigure 2.1.

Lemma 3. EJeKρ⇐⇒ E ′JeKρ, when dom(ρ) = fv(e).

In a linear program, each mapping in the environment corresponds to the singleoccurrence of a bound variable. So when evaluating an application, this tightening

39


splits the environment ρ into (ρ1, ρ2), where ρ1 closes the operator, ρ2 closes theoperand, and dom(ρ1) ∩ dom(ρ2) = ∅.

Definition 2. Environment ρ linearly closes t (or 〈t, ρ〉 is a linear closure) iff t islinear, ρ closes t, and for all x ∈ dom(ρ), x occurs exactly once (free) in t, ρ(x)is a linear closure, and for all y ∈ dom(ρ), x does not occur (free or bound) inρ(y). The size of a linear closure 〈t, ρ〉 is defined as:

|t, ρ| = |t|+ |ρ||x| = 1

|(λx.t`)| = 1 + |t||(t`11 t`22 )| = 1 + |t1|+ |t2|

|[x1 7→ c1, . . . , xn 7→ cn]| = n+∑i

|ci|

The following lemma states that evaluation of a linear closure cannot produce alarger value. This is the environment-based analog to the easy observation thatβ-reduction strictly decreases the size of a linear term.

Lemma 4. If ρ linearly closes t and E ′Jt`Kρ = c, then |c| ≤ |t, ρ|.

Proof. Straightforward by induction on |t, ρ|, reasoning by case analysis on t.Observe that the size strictly decreases in the application and variable case, andremains the same in the abstraction case.

The function lab(·) is extended to closures and environments by taking the unionof all labels in the closure or in the range of the environment, respectively.

Definition 3. The set of labels in a given term, expression, environment, or closureis defined as follows:

lab(t`) = lab(t) ∪ {`} lab(e1 e2) = lab(e1) ∪ lab(e2)lab(x) = {x} lab(λx.e) = lab(e) ∪ {x}

lab(t, ρ) = lab(t) ∪ lab(ρ) lab(ρ) =⋃x∈dom(ρ) lab(ρ(x))

Definition 4. A cache C, r respects 〈t, ρ〉 (written C, r ` t, ρ) when,

1. ρ linearly closes t,

40


2. ∀x ∈ dom(ρ).ρ(x) = 〈t′, ρ′〉 ⇒ r(x) = {t′} and C, r ` t′, ρ′,

3. ∀` ∈ lab(t), C(`) = ∅, and

4. ∀x ∈ bv(t), r(x) = ∅.

Clearly, ∅ ` t, ∅ when t is closed and linear, i.e. t is a linear

A0 : Exp× Cache→ Cache

A0Jx`K C, r = C[` 7→ r(x)], r

A0J(λx.e)`K C, r = C[` 7→ {λx.e}], rA0J(t`1 t`2)`K C, r = C3[` 7→ C3(`0)], r3, where

δ′ = dδèkC1, r1 = A0Jt`1K C, r

C2, r2 = A0Jt`2K C1, r1C3, r3 =⊔C2(`)

λx.t`0

(A0Jt`0K C2, r2[x 7→ C2(`2)]

)Figure 3.5: Abstract evaluator A0 for 0CFA, functional style.

Figure 3.5 gives a “cache-passing” functional algorithm for A0J·K of section 3.3.It is equivalent to the functional style abstract evaluator of Figure 2.6 specializedby letting k = 0. We now state and prove the main theorem of this section interms of this abstract evaluator.

Theorem 1. If C, r ` t, ρ, C(`) = ∅, ` /∈ lab(t, ρ), E ′Jt`Kρ = 〈t′, ρ′〉, andA0Jt`KC, r = C′, r′, then C′(`) = {t′}, C′ ` t′, ρ′, and C′, r′ |= t`.

An important consequence is noted in Corollary 1.

Proof. By induction on |t, ρ|, reasoning by case analysis on t.

• Case t ≡ x.

41


Since C ` x, ρ and ρ linearly closes x, thus ρ = [x 7→ 〈t′, ρ′〉] and ρ′ linearlycloses t′. By definition,

E ′Jx`Kρ = 〈t′, ρ′〉, and

A0Jx`KC = C[x↔ `].

Again since C ` x, ρ, C(x) = {t′}, with which the assumption C(`) = ∅implies

C[x↔ `](x) = C[x↔ `](`) = {t′},

and therefore C[x ↔ `] |= x`. It remains to show that C[x ↔ `] ` t′, ρ′.By definition, C ` t′, ρ′. Since x and ` do not occur in t′, ρ′ by linearityand assumption, respectively, it follows that C[x 7→ `] ` t′, ρ′ and the caseholds.

• Case t ≡ λx.e0.

By definition,

E ′J(λx.e0)`Kρ = 〈λx.e0, ρ〉,A0J(λx.e0)`KC = C[` 7→+ {λx.e0}],

and by assumption C(`) = ∅, so C[` 7→+ {λx.e0}](`) = {λx.e0} and there-fore C[` 7→+ {λx.e0}] |= (λx.e0)`. By assumptions ` /∈ lab(λx.e0, ρ) andC ` λx.e0, ρ, it follows that C[` 7→+ {λx.e0}] ` λx.e0, ρ and the case holds.

• Case t ≡ t`11 t`22 . Let

E ′Jt1Kρ� fv(t`11 ) = 〈v1, ρ1〉 = 〈λx.t`00 , ρ1〉,E ′Jt2Kρ� fv(t`22 ) = 〈v2, ρ2〉,

A0Jt1KC = C1, and

A0Jt2KC = C2.

Clearly, for i ∈ {1, 2}, C ` ti, ρ� fv(ti) and

1 +∑i

|tìi , ρ� fv(tìi )| = |(t`11 t`22 ), ρ|.

By induction, for i ∈ {1, 2} : Ci(ì) = {vi}, Ci ` 〈vi, ρi〉, and Ci |= tìi .From this, it is straightforward to observe that C1 = C∪ C′1 and C2 = C∪ C′2

42


where C′1 and C′2 are disjoint. So let C3 = (C1 ∪ C2)[x↔ `2]. It is clear thatC3 |= tìi . Furthermore,

C3 ` t0, ρ1[x 7→ 〈v2, ρ2〉],C3(`0) = ∅, and

`0 /∈ lab(t0, ρ1[x 7→ 〈v2, ρ2〉]).

By Lemma 4, |vi, ρi| ≤ |ti, ρ� fv(ti)|, therefore

|t0, ρ1[x 7→ 〈v2, ρ2〉]| < |(t`11 t`22 )|.

Let

E ′Jt`00 Kρ1[x 7→ 〈v2, ρ2〉] = 〈v′, ρ′〉,A0Jt`00 KC3 = C4,

and by induction, C4(`0) = {v′}, C4 ` v′, ρ′, and C4 |= v′. Finally, observethat C4[` ↔ `0](`) = C4[` ↔ `0](`0) = {v′}, C4[` ↔ `0] ` v′, ρ′, andC4[`↔ `0] |= (t`11 t`22 )`, so the case holds.

We can now establish the correspondence between analysis and evaluation.

Corollary 1. If C is the simple closure analysis of a linear program t`, thenE ′Jt`K∅ = 〈v, ρ′〉 where C(`) = {v} and C ` v, ρ′.

By a simple replaying of the proof substituting the containment constraints of0CFA for the equality constraints of simple closure analysis, it is clear that thesame correspondence can be established, and therefore 0CFA and simple closureanalysis are identical for linear programs.

Corollary 2. If e is a linear program, then C is the simple closure analysis of e iffC is the 0CFA of e.

Discussion: Returning to our earlier question of the computationally potent in-gredients in a static analysis, we can now see that when the term is linear, whetherflows are directional and bidirectional is irrelevant. For these terms, simple clo-sure analysis, 0CFA, and evaluation are equivalent. And, as we will see, when ananalysis is exact for linear terms, the analysis will have a PTIME-hardness bound.

43


3.5 Lower Bounds for Flow Analysis

There are at least two fundamental ways to reduce the complexity of analysis. Oneis to compute more approximate answers, the other is to analyze a syntacticallyrestricted language.

We use linearity as the key ingredient in proving lower bounds on analysis. Thisshows not only that simple closure analysis and other flow analyses are PTIME-complete, but the result is rather robust in the face of analysis design based onsyntactic restrictions. This is because we are able to prove the lower bound viaa highly restricted programming language—the linear λ-calculus. So long as thesubject language of an analysis includes the linear λ-calculus, and is exact for thissubset, the analysis must be at least PTIME-hard.

The decision problem answered by flow analysis, described in chapter 2, is for-mulated for monovariant analyses as follows:

Flow Analysis Problem: Given a closed expression e, a term v, and label `, isv ∈ C(`) in the analysis of e?

Theorem 2. If analysis corresponds to evaluation on linear terms, it is PTIME-hard.

The proof is by reduction from the canonical PTIME-complete problem of circuitevaluation (Ladner 1975):

Circuit Value Problem: Given a Boolean circuit C of n inputs and one output,and truth values ~x = x1, . . . , xn, is ~x accepted by C?

An instance of the circuit value problem can be compiled, using only logarithmicspace, into an instance of the flow analysis problem. The circuit and its inputsare compiled into a linear λ-term, which simulates C on ~x via evaluation—itnormalizes to true if C accepts ~x and false otherwise. But since the analysisfaithfully captures evaluation of linear terms, and our encoding is linear, the circuitcan be simulated by flow analysis.

The encodings work like this: tt is the identity on pairs, and ff is the swap.Boolean values are either 〈tt,ff〉 or 〈ff,tt〉, where the first component is the

44


“real” value, and the second component is the complement.

tt ≡ λp.let 〈x, y〉 = p in 〈x, y〉 True ≡ 〈tt,ff〉ff ≡ λp.let 〈x, y〉 = p in 〈y, x〉 False ≡ 〈ff,tt〉

The simplest connective is Not, which is an inversion on pairs, like ff. A linearcopy connective is defined as:

Copy ≡ λb.let 〈u, v〉 = b in 〈u〈tt,ff〉, v〈ff,tt〉〉.

The coding is easily explained: suppose b is True, then u is identity and v twists;so we get the pair 〈True,True〉. Suppose b is False, then u twists and v isidentity; we get 〈False,False〉. We write Copyn to mean n-ary fan-out—astraightforward extension of the above.

The And connective is defined as follows:

And ≡ λb1.λb2.let 〈u1, v1〉 = b1 inlet 〈u2, v2〉 = b2 inlet 〈p1, p2〉 = u1〈u2,ff〉 inlet 〈q1, q2〉 = v1〈tt, v2〉 in〈p1, q1 ◦ p2 ◦ q2 ◦ ff〉.

Conjunction works by computing pairs 〈p1, p2〉 and 〈q1, q2〉. The former is theusual conjunction on the first components of the Booleans b1, b2: u1〈u2,ff〉 canbe read as “if u1 then u2, otherwise false (ff).” The latter is (exploiting DeMorgan duality) the disjunction of the complement components of the Booleans:v1〈tt, v2〉 is read as “if v1 (i.e. if not u1) then true (tt), otherwise v2 (i.e. not u2).”The result of the computation is equal to 〈p1, q1〉, but this leaves p2, q2 unused,which would violate linearity. However, there is symmetry to this garbage, whichallows for its disposal. Notice that, while we do not know whether p2 is tt orff and similarly for q2, we do know that one of them is tt while the other is ff.Composing the two together, we are guaranteed that p2 ◦ q2 = ff. Composingthis again with another twist (ff) results in the identity function p2 ◦ q2 ◦ ff =tt. Finally, composing this with q1 is just equal to q1, so 〈p1, q1 ◦ p2 ◦ q2 ◦ff〉 = 〈p1, q1〉, which is the desired result, but the symmetric garbage has beenannihilated, maintaining linearity.

45


Similarly, we define truth-table implication:

Implies ≡ λb1.λb2.let 〈u1, v1〉 = b1 inlet 〈u2, v2〉 = b2 inlet 〈p1, p2〉 = u1〈u2,tt〉 inlet 〈q1, q2〉 = v1〈ff, v2〉 in〈p1, q1 ◦ p2 ◦ q2 ◦ ff〉

Let us work through the construction once more: Notice that if b1 is True, thenu1 is tt, so p1 is tt iff b2 is True. And if b1 is True, then v1 is ff, so q1 is ffiff b2 is False. On the other hand, if b1 is False, u1 is ff, so p1 is tt, and v1 istt, so q1 is ff. Therefore 〈p1, q1〉 is True iff b1 ⊃ b2, and False otherwise. Or,if you prefer, u1〈u2,tt〉 can be read as “if u1, then u2 else tt”—the if-then-elsedescription of the implication u1 ⊃ u2 —and v1〈ff, v2〉 as its De Morgan dual¬(v2 ⊃ v1). Thus 〈p1, q1〉 is the answer we want—and we need only dispensewith the “garbage” p2 and q2. De Morgan duality ensures that one is tt, and theother is ff (though we do not know which), so they always compose to ff.

However, simply returning 〈p1, q1〉 violates linearity since p2, q2 go unused. Weknow that p2 = tt iff q2 = ff and p2 = ff iff q2 = tt. We do not know whichis which, but clearly p2 ◦ q2 = ff ◦tt = tt ◦ff = ff. Composing p2 ◦ q2 withff, we are guaranteed to get tt. Therefore q1 ◦ p2 ◦ q2 ◦ ff = q1, and we haveused all bound variables exactly once.

This hacking, with its self-annihilating garbage, is an improvement over that givenby Mairson (2004) and allows Boolean computation without K-redexes, makingthe lower bound stronger, but also preserving all flows. In addition, it is the bestway to do circuit computation in multiplicative linear logic, and is how you com-pute similarly in non-affine typed λ-calculus (Mairson 2006b).

By writing continuation-passing style variants of the logic gates, we can encodecircuits that look like straight-line code. For example, define CPS logic gates asfollows:

Andgate ≡ λb1.λb2.λk.k(And b1 b2)

Orgate ≡ λb1.λb2.λk.k(Or b1 b2)

Impliesgate ≡ λb1.λb2.λk.k(Implies b1 b2)

Notgate ≡ λb.λk.k(Not b)

Copygate ≡ λb.λk.k(Copy b)

46


∧∧

∧

∨ ∨

∨

C

e1 e2 e3 e4 e5 e6

e7 e8

f

e9 e10

e11 e12

o

Figure 3.6: An example circuit.

Continuation-passing style code such as Andgate b1 b2 (λr.e) can be read collo-quially as a kind of low-level, straight-line assembly language: “compute the Andof registers b1 and b2, write the result into register r, and goto e.”

An example circuit is given in Figure 3.6, which can be encoded as:

Circuit ≡ λe1.λe2.λe3λe4.λe5.λe6.

Andgate e2 e3 (λe7.

Andgate e4 e5 (λe8.

Copygate f (λe9.λe10.

Orgate e1 e9 (λe11.

Orgate e10 e6 (λe12.

Orgate e11 e12 (λo.o))))))

Notice that each variable in this CPS encoding corresponds to a wire in the circuit.

The above code says:

• compute the And of e2 and e3, putting the result in register e7,

• compute the And of e4 and e5, putting the result in register e8,

• compute the And of e7 and e8, putting the result in register f ,

47


• make two copies of register f , putting the values in registers e9 and e10,

• compute the Or of e1 and e9, putting the result in register e11,

• compute the Or of e10 and e6, putting the result in register e12,

• compute the Or of e11 and e12, putting the result in the o (“output”) register.

We know from corollary 1 that evaluation and analysis of linear programs are syn-onymous, and our encoding of circuits will faithfully simulate a given circuit onits inputs, evaluating to true iff the circuit accepts its inputs. But it does not imme-diately follow that the circuit value problem can be reduced to the flow analysisproblem. Let ||C, ~x|| be the encoding of the circuit and its inputs. It is temptingto think the instance of the flow analysis problem could be stated:

is True in C(`) in the analysis of ||C, ~x||`?

The problem with this is there may be many syntactic instances of “True.” Sincethe flow analysis problem must ask about a particular one, this reduction will notwork. The fix is to use a context which expects a Boolean expression and inducesa particular flow (that can be asked about in the flow analysis problem) iff thatexpression evaluates to a true value.

We use The Widget to this effect. It is a term expecting a Boolean value. Itevaluates as though it were the identity function on Booleans, Widget b = b, butit induces a specific flow we can ask about. If a true value flows out of b, thenTrueW flows out of Widget b. If a false value flows out of b, then FalseWflows out of Widget b, where TrueW and FalseW are distinguished terms, andthe only possible terms that can flow out. We usually drop the subscripts and say“does True flow out of Widget b?” without much ado.

Widget ≡ λb.

let 〈u, v〉 = b inlet 〈x, y〉 = u〈f, g〉 inlet 〈x′, y′〉 = u′〈f ′, g′〉 in〈〈xa, yn〉, 〈x′a′, y′b′〉〉

Because the circuit value problem is complete for PTIME, we conclude:

48


Theorem 3. The control flow problem for 0CFA is complete for PTIME.

Corollary 3. The control flow problem for simple closure analysis is complete forPTIME.

3.6 Other Monovariant Analyses

In this section, we survey some of the existing monovariant analyses that eitherapproximate or restrict 0CFA to obtain faster analysis times. In each case, wesketch why these analyses are complete for PTIME.

Shivers (2004) noted in his retrospective on control flow analysis that “in the en-suing years [since 1988], researchers have expended a great deal of effort derivingclever ways to tame the cost of the analysis.” Such an effort prompts a fundamen-tal question: to what extent is this possible?

Algorithms to compute 0CFA were long believed to be at least cubic in the size ofthe program, proving impractical for the analysis of large programs, and Heintzeand McAllester (1997c) provided strong evidence to suggest that in general, thiscould not be improved. They reduced the problem of computing 0CFA to that ofdeciding two-way nondeterministic push-down automata acceptance (2NPDA);a problem whose best known algorithm was cubic and had remained so since itsdiscovery (Aho et al. 1968)—or so it was believed; see section 6.4 for a discussion.

In the face of this likely insurmountable bottleneck, researchers derived waysof further approximating 0CFA, thereby giving up information in the service ofquickly computing a necessarily less precise analysis in order to avoid the “cubicbottleneck.”

Such further approximations enjoy linear or near linear algorithms and have be-come widely used for the analysis of large programs where the more precise 0CFAwould be to expensive to compute. But it is natural to wonder if the algorithms forthese simpler analyses could be improved. Owing to 0CFA’s PTIME-lower bound,its algorithms are unlikely to be effectively parallelized or made memory efficient.But what about these other analyses?

49


3.6.1 Ashley and Dybvig’s Sub-0CFA

Ashley and Dybvig (1998) developed a general framework for specifying andcomputing flow analyses; instantiations of the framework include 0CFA and thepolynomial 1CFA of Jagannathan and Weeks (1995), for example. They alsodeveloped a class of instantiations, dubbed sub-0CFA, that are faster to compute,but less accurate than 0CFA.

This analysis works by explicitly bounding the number of times the cache can beupdated for any given program point. After this threshold has been crossed, thecache is updated with a distinguished unknown value that represents all possibleλ-abstractions in the program. Bounding the number of updates to the cache forany given location effectively bounds the number of passes over the program ananalyzer must make, producing an analysis that isO(n) in the size of the program.Empirically, Ashley and Dybvig observe that setting the bound to 1 yields aninexpensive analysis with no significant difference in enabling optimizations withrespect to 0CFA.

The idea is the cache gets updated once (n times in general) before giving up andsaying all λ-abstractions flow out of this point. But for a linear term, the cache isonly updated at most once for each program point. Thus we conclude even whenthe sub-0CFA bound is 1, the problem is PTIME-complete.

As Ashley and Dybvig note, for any given program, there exists an analysis in thesub-0CFA class that is identical to 0CFA (namely by setting n to the number ofpasses 0CFA makes over the given program). We can further clarify this relation-ship by noting that for all linear programs, all analyses in the sub-0CFA class areidentical to 0CFA (and thus simple closure analysis).

3.6.2 Subtransitive 0CFA

Heintze and McAllester (1997c) have shown the “cubic bottleneck” of computingfull 0CFA—that is, computing all the flows in a program—cannot be avoided ingeneral without combinatorial breakthroughs: the problem is 2NPDA-hard, forwhich the “the cubic time decision procedure [. . . ] has not been improved sinceits discovery in 1968.”

Forty years later, that decision procedure was improved to be slightly subcubicby Chaudhuri (2008). However, given the strong evidence at the time that the

50


situation was unlikely to improve in general, Heintze and McAllester (1997a)identified several simpler flow questions4 and designed algorithms to answer themfor simply-typed programs. Under certain typing conditions, namely that the typeis within a bounded size, these algorithms compute in less than cubic time.

The algorithm constructs a graph structure and runs in time linear in a program’sgraph. The graph, in turn, is bounded by the size of the program’s type. Thus,bounding the size of a program’s type results in a linear bound on the runningtimes of these algorithms.

If this type bound is removed, though, it is clear that even these simplified flowproblems (and their bidirectional-flow analogs), are complete for PTIME: observethat every linear term is simply typable, however in our lower bound construction,the type size is proportional to the size of the circuit being simulated. As theypoint out, when type size is not bounded, the flow graph may be exponentiallylarger than the program, in which case the standard cubic algorithm is preferred.

Independently, Mossin (1998) developed a type-based analysis that, under theassumption of a constant bound on the size of a program’s type, can answer re-stricted flow questions such as single source/use in linear time with respect to thesize of the explicitly typed program. But again, removing this imposed boundresults in PTIME-completeness.

As Hankin et al. (2002) point out: both Heintze and McAllester’s and Mossin’salgorithms operate on type structure (or structure isomorphic to type structure),but with either implicit or explicit η-expansion. For simply-typed terms, this canresult in an exponential blow-up in type size. It is not surprising then, that given amuch richer graph structure, the analysis can be computed quickly.

In this light, the results of chapter 4 on 0CFA of η-expanded, simply-typed pro-grams can be seen as an improvement of the subtransitive flow analysis since itworks equally well for languages with first-class control and can be performedwith only a fixed number of pointers into the program structure, i.e. it is com-putable in LOGSPACE (and in other words, PTIME = LOGSPACE up to η).

4Including the decision problem discussed in this dissertation, which is the simplest; answers toany of the other questions imply an answer to this problem

51


3.7 Conclusions

When an analysis is exact, it will be possible to establish a correspondence withevaluation. The richer the language for which analysis is exact, the harder it willbe to compute the analysis. As an example in the extreme, Mossin (1997a) devel-oped a flow analysis that is exact for simply-typed terms. The computational re-sources that may be expended to compute this analysis are ipso facto not boundedby any elementary recursive function (Statman 1979). However, most flow analy-ses do not approach this kind of expressivity. By way of comparison, 0CFA onlycaptures PTIME, and yet researchers have still expending a great deal of effort de-riving approximations to 0CFA that are faster to compute. But as we have shownfor a number of them, they all coincide on linear terms, and so they too capturePTIME.

We should be clear about what is being said, and not said. There is a considerabledifference in practice between linear algorithms (nominally considered efficient)and cubic—or near cubic—algorithms (still feasible, but taxing for large inputs),even though both are polynomial-time. PTIME-completeness does not distinguishthe two. But if a sub-polynomial (e.g., LOGSPACE) algorithm was found for thissort of flow analysis, it would depend on (or lead to) things we do not know(LOGSPACE = PTIME).

Likewise, were a parallel implementation of this flow analysis to run in logarith-mic time (i.e., NC), we would consequently be able to parallelize every polynomialtime algorithm. PTIME-complete problems are considered to be the least likely tobe in NC. This is because logarithmic-space reductions (such as our compilerfrom circuits to λ-terms) preserve parallel complexity, and so by composing thisreduction with a (hypothetical) logarithmic-time 0CFA analyzer (or equivalently,a logarithmic-time linear λ-calculus evaluator) would yield a fast parallel algo-rithm for all problems in PTIME, which are by definition, logspace-reducible tothe circuit value problem (Papadimitriou 1994, page 377).

The practical consequences of the PTIME-hardness result is that we can concludeany analysis which is exact for linear programs, which includes 0CFA, and manyfurther approximations, does not have a fast parallel algorithm unless PTIME =NC.

52

Chapter 4

Linear Logic and Static Analysis

If you want to understand exactly how and where static analysis is computation-ally difficult, you need to know about linearity. In this chapter, we develop analternative, graphical representation of programs that makes explicit both non-linearity and control, and is suitable for static analysis.

This alternative representation offers the following benefits:

• It provides clear intuitions on the essence of 0CFA and forms the basis for atransparent proof of the correspondence between 0CFA and evaluation forlinear programs.

• As a consequence of symmetries in the notation, it is equally well-suited forrepresenting programs with first-class control.

• It based on the technology of linear logic. Insights gleaned from linear logic,viewed through the lens of a Curry-Howard correspondence, can informprogram analysis and vice versa.

• As an application of the above, a novel and efficient algorithm for analyzingtyped programs (section 4.4) is derived from recent results on the efficientnormalization of linear logic proofs.

We give a reformulation of 0CFA in this setting and then transparently reprovethe main result of section 3.4: analysis and evaluation are synonymous for linearprograms.

53

CHAPTER 4. LINEAR LOGIC AND STATIC ANALYSIS

4.1 Sharing Graphs for Static Analysis

In general, the sharing graph of a term will consist of a distinguished root wirefrom which the rest of the term’s graph “hangs.”

M

fv(M)

At the bottom of the graph, the dangling wires represent free variables and connectto occurrences of the free variable within in term.

Graphs consist of ternary abstraction (λ), apply (@), sharing (O) nodes, and unaryweakening (�) nodes. Each node has a distinguished principal port. For unarynodes, this is the only port. The ternary nodes have two auxiliary ports, distin-guished as the white and black ports.

• A variable occurrence is represented simply as a wire from the root to thefree occurrence of the variable.

x

x

• Given the graph for M , where x occurs free,

M

fv(M) \ {x} x

54


the abstraction λx.M is formed as,

λx.M, x ∈ fv(M)M

fv(M) \ {x}

λ

Supposing x does not occur inM , the weakening node (�) is used to “plug”the λ variable wire.

λx.M, x /∈ fv(M)M

fv(M)

λ

�

• Given graphs for M and N ,

M N

fv(M) fv(N) ,

55


@ @ @@

λx

⇒cfa

λx λx

⇒cfa

λx

Figure 4.1: CFA virtual wire propagation rules.

the application MN is formed as,

M N

@

MN

fv(N) \ fv(M)

fv(N) ∩ fv(M)

fv(M) \ fv(N)

.

An application node is introduced. The operator M is connected to thefunction port and the operand N is connected to the argument port. Thecontinuation wire becomes the root wire for the application. Free variablesshared between both M and N are fanned out with sharing nodes.

4.2 Graphical 0CFA

We now describe an algorithm for performing control flow analysis that is basedon the graph coding of terms. The graphical formulation consists of generating aset of virtual paths for a program graph. Virtual paths describe an approximationof the real paths that will arise during program execution.

Figure 4.1 defines the virtual path propagation rules. Note that a wire can be

56


identified by its label or a variable name.1 The left hand rule states that a virtualwire is added from the continuation wire to the body wire and from the variablewire to the argument wire of each β-redex. The right hand rule states analogouswires are added to each virtual β-redex—an apply and lambda node connected bya virtual path. There is a virtual path between two wires ` and `′, written ` `′

in a CFA-graph iff:

1. ` ≡ `′.

2. There is a virtual wire from ` to `′.

3. ` connects to an auxiliary port and `′ connects to the root port of a sharingnode.

4. There is a virtual path from ` to `′′ and from `′′ and `′.

Reachability: Some care must be taken to ensure leastness when propagatingvirtual wires. In particular, wires are added only when there is a virtual pathbetween a reachable apply and a lambda node. An apply node is reachable if it ison the spine of the program, i.e., if e = (· · · ((e0e1)`1e2)`2 · · · en)`n then the applynodes with continuation wires labeled `1, . . . , `n are reachable, or it is on the spineof an expression with a virtual path from a reachable apply node.

Reachability is usually explained as a known improvement to flow analysis; pre-cision is increased by avoiding parts of the program that cannot be reached (Ayers1993; Palsberg and Schwartzbach 1995; Biswas 1997; Heintze and McAllester1997b; Midtgaard and Jensen 2008, 2009).

But reachability can also be understood as an analysis analog to weak normaliza-tion. Reachability says roughly: “don’t analyze under λ until the analysis deter-mines it may be applied.” On the other hand, weak normalization says: “don’tevaluate under λ until the evaluator determines it is applied.” The analyzers ofchapter 2 implicitly include reachability since they are based on a evaluation func-tion that performs weak normalization.

The graph-based analysis can now be performed in the following way: con-struct the CFA graph according to the rules in Figure 4.1, then define C(`) as{(λx.e)`′ | ` `′} and r(x) as {(λx.e)` | x `}. It is easy to see that the

1We implicitly let ` range over both in the following definitions.

57


@

@

@

@

@

@

λf

λx

λy

10

1 2

4

5

3

8

9

6

7

λf

λx

λy

10

1 2

4

5

3

8

9

6

7

Figure 4.2: Graph coding and CFA graph of (λf.ff(λy.y))(λx.x).

algorithm constructs answers that satisfy the acceptability relation specifying theanalysis. Moreover, this algorithm constructs least solutions according to the par-tial order given in section 2.3.

Lemma 5. C′, r′ |= e implies C, r v C′, r′ for C, r constructed for e as describedabove.

We now consider an example of use of the algorithm. Consider the labeled pro-gram:

((λf.((f 1f 2)3(λy.y4)5)6)7(λx.x8)9)10

Figure 4.2 shows the graph coding of the program and the corresponding CFAgraph. The CFA graph is constructed by adding virtual wires 10 6 and f 9,induced by the actual β-redex on wire 7. Adding the virtual path f 9 to thegraph creates a virtual β-redex via the route 1 f (through the sharing node),and f 9 (through the virtual wire). This induces 3 8 and 8 2. There isnow a virtual β-redex via 3 8 2 f 9, so wires 6 8 and 8 5 areadded. This addition creates another virtual redex via 3 8 2 5, whichinduces virtual wires 6 4 and 4 5. No further wires can be added, so the

58


CFA graph is complete. The resulting abstract cache gives:

C(1) = {λx} C(6) = {λx, λy}C(2) = {λx} C(7) = {λf}C(3) = {λx, λy} C(8) = {λx, λy}C(4) = {λy} C(9) = {λx}C(5) = {λy} C(10) = {λx, λy}

r(f) = {λx}r(x) = {λx, λy}r(y) = {λy}

4.3 Multiplicative Linear Logic

The Curry-Howard isomorphism states a correspondence between logical systemsand computational calculi (Howard 1980). The fundamental idea is that data typesare theorems and typed programs are proofs of theorems.

It begins with the observation that an implicationA→ B correspondsto a type of functions from A to B, because inferring B from A →B and A can be seen as applying the first assumption to the secondone—just like a function from A to B applied to an element of Ayields an element of B. (Sørensen and Urzyczyn 2006, p. v)

For the functional programmer, the most immediate correspondence is betweenproofs in propositional intuitionistic logic and simply typed λ-terms. But the cor-respondence extends considerably further.

Virtually all proof-related concepts can be interpreted in terms ofcomputations, and virtually all syntactic features of various lambda-calculi and similar systems can be formulated in the language of prooftheory.

In this section we want to develop the “proofs-as-programs” correspondence forlinear programs, an important class of programs to consider for lower bounds onprogram analysis. Because analysis and evaluation are synonymous for linearprograms, insights from proof evaluation can guide new algorithms for programanalysis.

59


The correspondence between simply typed (nonlinear) terms and intuitionisticlogic can be seen by looking at the familiar typing rules:

VARΓ, x : A ` x : A

ABSΓ, x : A `M : B

Γ ` λx.M : A→ B

APPΓ `M : A→ B Γ ` N : A

Γ `MN : B

If you ignore the “proof terms” (i.e. the programs), you get intuitionsitic sequentcalculus:

AXΓ, A ` A

→IΓ, A ` B

Γ ` A→ B→E

Γ ` A→ B Γ ` AΓ ` B

Likewise, linear programs have their own logical avatar, namely multiplicativelinear logic.

4.3.1 Proofs

Each atomic formula is given in two forms: positive (A) and negative (A⊥) andthe linear negation of A is A⊥ and vice versa. Negation is extended to compoundformulae via De Morgan laws:

(A⊗B)⊥ = A⊥OB⊥ (AOB)⊥ = A⊥ ⊗B⊥

A two sided sequent

A1, . . . , An ` B1, . . . , Bm

is replaced by

` A⊥1 , . . . , A⊥n , B1, . . . , Bm

The interested reader is referred to Girard (1987) for more details on linear logic.

For each derivation in MLL, there is a proofnet, which abstracts away much of theneedless sequentialization of sequent derivations, “like the order of application

60


of independent logical rules: for example, there are many inessintailly differentways to obtain ` A1OA2, . . . An−1OAn from ` A1, . . . An, while there is onlyone proof net representing all these derivations” (Di Cosmo et al. 2003). There isstrong connection with calculus of explicit substitutions Di Cosmo et al. (2003).

The sequent rules of multiplicative linear logic (MLL) are given in Figure 4.3.

AXA,A⊥

CUTΓ, A A⊥,∆

Γ,∆O

Γ, A,B

Γ, AOB⊗

Γ, A ∆, B

Γ,∆, A⊗B

Figure 4.3: MLL sequent rules.

4.3.2 Programs

These rules have an easy functional programming interpretation as the types ofa linear programming language (eg. linear ML), following the intuitions of theCurry-Howard correspondence (Girard et al. 1989; Sørensen and Urzyczyn 2006).2

(These are written in the more conventional (to functional programmers) two-sided sequents, but just remember that A⊥ on the left is like A on the right).

x : A ` x : A

Γ `M : A ∆ ` N : B

Γ,∆ ` (M,N) : A⊗BΓ, x : A `M : B

Γ ` λx.M : A( B

Γ `M : A( B ∆ ` N : A

Γ,∆ `MN : B

Γ `M : A⊗B ∆, x : A, y : B ` N : C

Γ,∆ ` let 〈x, y〉 = M in N : C

The AXIOM rule says that a variable can be viewed simultaneously as a continua-tion (A⊥) or as an expression (A)—one man’s ceiling is another man’s floor. Thuswe say “input of type A” and “output of type A⊥” interchangeably, along withsimilar dualisms. We also regard (A⊥)⊥ synonymous with A: for example, Int

2For a more detailed discussion of the C.-H. correspondence between linear ML and MLL, seeMairson (2004).

61


is an integer, and Int⊥ is a request (need) for an integer, and if you need to needan integer—(Int⊥)⊥—then you have an integer.

The CUT rule says that if you have two computations, one with an output of typeA, another with an input of type A, you can plug them together.

The ⊗-rule is about pairing: it says that if you have separate computations pro-ducing outputs of types A and B respectively, you can combine the computationsto produce a paired output of type A⊗ B. Alternatively, given two computationswith A an output in one, and B an input (equivalently, continuation B⊥ an output)in the other, they get paired as a call site “waiting” for a function which producesan output of type B with an input of type A. Thus ⊗ is both cons and functioncall (@).

The O-rule is the linear unpairing of this ⊗-formation. When a computation usesinputs of types A and B, these can be combined as a single input pair, e.g., let(x,y)=p in.... Alternatively, when a computation has an input of type A(output of continuation of type A⊥) and an output of type B, these can be com-bined to construct a function which inputs a call site pair, and unpairs them appro-priately. Thus O is both unpairing and λ.

4.4 η-Expansion and LOGSPACE

4.4.1 Atomic versus Non-Atomic Axioms

The above AXIOM rule does not make clear whether the formula A is an atomictype variable or a more complex type formula. When a linear program onlyhas atomic formulas in the “axiom” position, then we can evaluate (normalize)it in logarithmic space. When the program is not linear, we can similarly com-pute a 0CFA analysis in LOGSPACE. Moreover, these problems are complete forLOGSPACE.

MLL proofs with non-atomic axioms can be easily converted to ones with atomic

62


@

@

@

@ @

@

@ @ @

@

@

@σ

λx

λy

λx

σ σ′⇒σ′ → σ

λx

λy

λx

σ′⇒ σσ′ → σ

λx.ee′ ⇒ ⇒

σ′ → σ

⇒ ⇒λxλx λz

λyλx

λz

σ′ → σ

e0(e1e2) ⇒ e0(λy.e1e2y) λx.C[λz.x] ⇒ λx.λy.C[λz.zy]

⇒ λx.λy.xy

λx.C[e(λy.xy)]λx.C[ex]λx.λy.ee′y

λx.x

σ′ σ′σ

Figure 4.4: Expansion algorithm.

axioms using the following transformation, analogous to η-expansion:

α⊗ β, α⊥Oβ⊥⇒

α, α⊥ β, β⊥

α⊗ β, α⊥, β⊥

α⊗ β, α⊥Oβ⊥

This transformation can increase the size of the proof. For example, in the circuitexamples of the previous section (which are evidence for PTIME-completeness),η-expansion causes an exponential increase in the number of proof rules used.3 ALOGSPACE evaluation is then polynomial-time and -space in the original circuitdescription.3It is linear in the formulas used, whose length increases exponentially (not so if the formulas arerepresented by directed acyclic graphs).

63


The program transformation corresponding to the above proof expansion is a ver-sion of η-expansion: see Figure 4.4. The left hand expansion rule is simply η,dualized in the unusual right hand rule. The right rule is written with the @ abovethe λ only to emphasis its duality with the left rule. Although not shown in thegraphs, but implied by the term rewriting rules, an axiom may pass through anynumber of sharing nodes.

4.4.2 Proof Normalization with Non-Atomic Axioms: PTIME

A normalized linear program has no redexes. From the type of the program, onecan reconstruct—in a totally syntax-directed way—what the structure of the termis (Mairson 2004). It is only the position of the axioms that is not revealed. Forexample, both TT and FF from the above circuit example have type ’a * ’a-> ’a * ’a.4 From this type, we can see that the term is a λ-abstraction, theparameter is unpaired—and then, are the two components of type a repaired asbefore, or “twisted”? To twist or not to twist is what distinguishes TT from FF.

An MLL proofnet is a graphical analogue of an MLL proof, where various se-quentialization in the proof is ignored. The proofnet consists of axiom, cut, ⊗,and O nodes with various dangling edges corresponding to conclusions. Rules forproofnet formation (Figure 4.5) follow the rules for sequent formation (Figure 4.3)almost identically.

⇒axax

cut

Π

Γ AB

⇒Π

ΓOAOB

A A⊥

Π′Π Π Π′

∆ ∆Γ ΓA A⊥

⇒

Π Π′

Γ A B ∆

⇒Π Π′

⊗∆Γ A⊗ B

Π

Γ AB

⇒Π

ΓOAOB

A A⊥

Π′Π Π Π′

∆ ∆Γ A A⊥

Π Π′

Γ A B ∆

⇒Π Π′

⊗∆Γ A⊗ B

Γ

Figure 4.5: MLL proofnets.

4The linear logic equivalent is (α⊥Oα⊥)O(α ⊗ α). The λ is represented by the outer O, theunpairing by the inner O, and the consing by the ⊗.

64


A binary axiom node has two dangling edges, typed A and A⊥. Given two dis-joint proofnets with dangling edges (conclusions) typed Γ, A andA⊥,∆, the edgestyped A,A⊥ can be connected to a binary cut node, and the resulting connectedproofnet has dangling edges typed Γ,∆. Given a connected proofnet with dan-gling wires typed Γ, A,B, the edges typed A,B can be connected to the two aux-iliary port of a O node and the dangling edge connected to the principal port willhave type AOB. Finally, given two disjoint proofnets with dangling edges typedΓ, A and ∆, B, the edges typed A,B can be connected to the two auxiliary portsof a ternary ⊗ node; the principal port then has a dangling wire of type A ⊗ B.The intuition is that ⊗ is pairing and O is linear unpairing.

The geometry of interaction (Girard 1989; Gonthier et al. 1992)—the semantics oflinear logic—and the notion of paths provide a way to calculate normal forms, andmay be viewed as the logician’s way of talking about static program analysis.5 Tounderstand how this analysis works, we need to have a graphical picture of whata linear functional program looks like.

Without loss of generality, such a program has a type φ. Nodes in its graphicalpicture are either λ or linear unpairing (O in MLL), or application/call site orlinear pairing (⊗ in MLL). We draw the graphical picture so that axioms are ontop, and cuts (redexes, either β-redexes or pair-unpair redexes) are on the bottomas shown in Figure 4.6.

α⊥

· · ·

cut cut

ax ax

ψ ψ⊥ ρ ρ⊥φ

α α⊥αα⊥α

Figure 4.6: MLL proofnet with atomic axioms.

Because the axioms all have atomic type, the graph has the following nice prop-erty:

Lemma 6. Begin at an axiom α and “descend” to a cut-link, saving in an (initiallyempty) stack whether nodes are encountered on their left or right auxiliary port.

5See Mairson (2002) for an introduction to context semantics and normalization by static analysisin the geometry of interaction.

65


Once a cut is reached, “ascend” the accompanying structure, popping the stackand continuing left or right as specified by the stack token. Then (1) the stackempties exactly when the next axiom α′ is reached, and (2) if the k-th node fromthe start traversed is a ⊗, the k-th node from the end traversed is a O, and viceversa.

The path traced in the Lemma, using the stack, is geometry of interaction (GoI),also known as static analysis. The correspondence between the k-th node from thestart and end of the traversal is precisely that between a call site (⊗) and a calledfunction (O), or between a cons (⊗) and a linear unpairing (O).

4.4.3 Proof Normalization with Atomic Axioms: LOGSPACE

A sketch of the “four finger” normalization algorithm: The stack height may bepolynomial, but we do not need the stack! Put fingers α, β on the axiom where thepath begins, and iterate over all possible choices of another two fingers α′, β′ atanother axiom. Now move β and β′ towards the cut link, where if β encounters anode on the left (right), then β′ must move left (right) also. If α′, β′ were correctlyplaced initially, then when β arrives at the cut link, it must be met by β′. If β′ isn’tthere, or got stuck somehow, then α′, β′ were incorrectly placed, and we iterate toanother placement and try again.

Lemma 7. Any path from axiom α to axiom α′ traced by the stack algorithm of theprevious lemma is also traversed by the “four finger” normalization algorithm.

Normalization by static analysis is synonymous with traversing these paths. Be-cause these fingers can be stored in logarithmic space, we conclude (Terui 2002;Mairson 2006a,b):

Theorem 4. Normalization of linear, simply-typed, and fully η-expanded func-tional programs is contained in LOGSPACE.

That 0CFA is then contained in LOGSPACE is a casual byproduct of this theorem,due to the following observation: if application site χ calls function φ, then the⊗ and O (synonymously, @ and λ) denoting call site and function are in distincttrees connected by a CUT link. As a consequence the 0CFA computation is asubcase of the four-finger algorithm: traverse the two paths from the nodes to

66


the cut link, checking that the paths are isomorphic, as described above. The full0CFA calculation then iterates over all such pairs of nodes.

Corollary 4. 0CFA of linear, simply-typed, and fully η-expanded functional pro-grams is contained in LOGSPACE.

4.4.4 0CFA in LOGSPACE

Now let us remove the linearity constraint, while continuing to insist on full η-expansion as described above, and simple typing. The normalization problem isno longer contained in LOGSPACE, but rather non-elementary recursive, (Statman1979; Mairson 1992b; Asperti and Mairson 1998). However, 0CFA remains con-tained in LOGSPACE, because it is now an approximation. This result follows fromthe following observation:

Lemma 8. Suppose (t` e) occurs in a simply typed, fully η-expanded program andλx.e ∈ C(`). Then the corresponding ⊗ and O occur in adjacent trees connectedat their roots by a CUT-link and on dual, isomorphic paths modulo placement ofsharing nodes.

Here “modulo placement” means: follow the paths to the cut—then we encounter⊗ (resp., O) on one path when we encounter O (resp.,⊗) on the other, on the same(left, right) auxiliary ports. We thus ignore traversal of sharing nodes on each pathin judging whether the paths are isomorphic. (Without sharing nodes, the ⊗ andO would annihilate—i.e., a β-redex—during normalization.)

Theorem 5. 0CFA of a simply-typed, fully η-expanded program is contained inLOGSPACE.

Observe that 0CFA defines an approximate form of normalization which is sug-gested by simply ignoring where sharing occurs. Thus we may define the set ofλ-terms to which that a term might evaluate. Call this 0CFA-normalization.

Theorem 6. For fully η-expanded, simply-typed terms, 0CFA-normalization canbe computed in nondeterministic LOGSPACE.

Conjecture 1. For fully η-expanded, simply-typed terms, 0CFA-normalization iscomplete for nondeterministic LOGSPACE.

67


The proof of the above conjecture likely depends on a coding of arbitrary directedgraphs and the consideration of commensurate path problems.

Conjecture 2. An algorithm for 0CFA normalization can be realized by optimalreduction, where sharing nodes always duplicate, and never annihilate.

4.4.5 LOGSPACE-hardness of Normalization and 0CFA: linear,simply-typed, fully η-expanded programs

That the normalization and 0CFA problem for this class of programs is as hard asany LOGSPACE problem follows from the LOGSPACE-hardness of the permutationproblem: given a permutation π on 1, . . . , n and integer 1 ≤ i ≤ n, are 1 and i onthe same cycle in π? That is, is there a k where 1 ≤ k ≤ n and πk(1) = i?

Briefly, the LOGSPACE-hardness of the permutation problem is as follows.6 Givenan arbitrary LOGSPACE Turing machine M and an input x to it, visualize a graphwhere the nodes are machine IDs, with directed edges connecting successive con-figurations. Assume that M always accepts or rejects in unique configurations.Then the graph has two connected components: the “accept” component, and the“reject” component. Each component is a directed tree with edges pointing to-wards the root (final configuration). Take an Euler tour around each component(like tracing the fingers on your hand) to derive two cycles, and thus a permuta-tion on machine IDs. Each cycle is polynomial size, because the configurationsonly take logarithmic space. The equivalent permutation problem is then: doesthe initial configuration and the accept configuration sit on the same cycle?

The following linear ML code describes the “target” code of a transformation ofan instance of the permutation problem. For a permutation on n letters, we takehere an example where n = 3. Begin with a vector of length n set to False, anda permutation on n letters:

- val V= (False,False,False);val V = ((fn,fn),(fn,fn),(fn,fn))

: ((’a * ’a -> ’a * ’a) * (’a * ’a -> ’a * ’a))

* ((’a * ’a -> ’a * ’a) * (’a * ’a -> ’a * ’a))

* ((’a * ’a -> ’a * ’a) * (’a * ’a -> ’a * ’a))

6This presentation closely follows Mairson (2006b).

68


Denote as ν the type of vector V.

- fun Perm (P,Q,R)= (Q,R,P);val Perm = fn : ν -> ν

The function Insert linearly inserts True in the first vector component, usingall input exactly once:

- fun Insert ((p,p’),Q,R)= ((TT,Compose(p,p’)),Q,R);val Insert = fn : ν -> ν

The function Select linearly selects the third vector component:

- fun Select (P,Q,(r,r’))=(Compose (r,Compose (Compose P, Compose Q)),r’);

val Select = fn: ν -> ((’a * ’a -> ’a * ’a) * (’a * ’a -> ’a * ’a))

Because Perm and Insert have the same flat type, they can be composed iter-atively in ML without changing the type. (This clearly is not true in our codingof circuits, where the size of the type increases with the circuit. A careful codinglimits the type size to be polynomial in the circuit size, regardless of circuit depth.)

Lemma 9. Let π be coded as permutation Perm. Define Foo to be

Compose(Insert,Perm)

composed with itself n times. Then 1 and i are on the same cycle of π iff Select(Foo V) normalizes to True.

Because 0CFA of a linear program is identical with normalization, we conclude:

Theorem 7. 0CFA of a simply-typed, fully η-expanded program is complete forLOGSPACE.

The usefulness of η-expansion has been noted in the context of partial evaluation(Jones et al. 1993; Danvy et al. 1996). In that setting, η-redexes serve to syntacti-cally embed binding-time coercions. In our case, the type-based η-expansion doesthe trick of placing the analysis in LOGSPACE by embedding the type structure intothe syntax of the program.7

7Or, in slogan form: LOGSPACE = PTIME upto η.

69


4.5 Graphical Flow Analysis and Control

Shivers (2004) argues that “CPS provide[s] a uniform representation of controlstructure,” allowing “this machinery to be employed to reason about context, aswell,” and that “without CPS, separate contextual analyses and transforms mustbe also implemented—redundantly,” in his view. Although our formulation offlow analysis is a “direct-style” formulation, a graph representation enjoys thesame benefits of a CPS representation, namely that control structures are madeexplicit—in a graph a continuation is simply a wire. Control constructs such ascall/cc can be expressed directly (Lawall and Mairson 2000) and our graphicalformulation of control flow analysis carries over without modification.

Lawall and Mairson (2000) derive graph representations of programs with con-trol operators such as call/cc by first translating programs into continuationpassing style (CPS). They observed that when edges in the CPS graphs carry-ing answer values (of type ⊥) are eliminated, the original (direct-style) graph isregained, modulo placement of boxes and croissants that control sharing. Com-posing the two transformations results in a direct-style graph coding for languageswith call/cc (hereafter, λK). The approach applies equally well to languagessuch as Filinski’s symmetric λ-calculus (1989), Parigot’s λµ calculus (1992), andmost any language expressible in CPS.

Languages such as λξ, which contains the “delimited control” operators shift andreset (Danvy and Filinski 1990), are not immediately amenable to this approachsince the direct-style transformation requires all calls to functions or continuationsbe in tail position. Adapting this approach to such languages constitutes an openarea of research.

The left side of Figure 4.7 shows the graph coding of call/cc. Examining thisgraph, we can read of an interpretation of call/cc, namely: call/cc is afunction that when applied, copies the current continuation (4) and applies thegiven function f to a function (λv . . .) that when applied abandons the contin-uation at that point (�) and gives its argument v to a copy of the continuationwhere call/cc was applied. If f never applies the function it is given, thencontrol returns “normally” and the value f returns is given to the other copy of thecontinuation where call/cc was applied.

The right side of Figure 4.7 gives the CFA graph for the program:

(call/cc (λk.(λx.1)(k2)))`

70


@ @

@

@ @

λk

λf

λv�

call/cc

λf

λv�

�λx

2

1

Figure 4.7: Graph coding of call/cc and example CFA graph.

From the CFA graph we see that C(`) = {1, 2}, reflecting the fact that the programwill return 1 under a call-by-name reduction strategy and 2 under call-by-value.Thus, the analysis is indifferent to the reduction strategy. Note that whereas be-fore, approximation was introduced through nonlinearity of bound variables, ap-proximation can now be introduced via nonlinear use of continuations, as seenin the example. In the same way that 0CFA considers all occurrences of a boundvariable “the same”, 0CFA considers all continuations obtained with each instanceof call/cc “the same”.

Note that we can ask new kinds of interesting questions in this analysis. For exam-ple, in Figure 4.7, we can compute which continuations are potentially discarded,by computing which continuations flow into the weakening node of the call/ccterm. (The answer is the continuation ((λx.1)[ ]).) Likewise, it is possible to askwhich continuations are potentially copied, by computing which continuationsflow into the principal port of the sharing node in the call/cc term (in this case,the top-level empty continuation [ ]). Because continuations are used linearly incall/cc-free programs, the questions were uninteresting before—the answer isalways none.

Our proofs for the PTIME-completeness of 0CFA for the untyped λ-calculus carryover without modification languages such as λK, λµ and the symmetric λ-calculus.In other words, first-class control operators such as call/cc increase the expres-sivity of the language, but add nothing to the computational complexity of controlflow analysis. In the case of simply-typed, fully η-expanded programs, the same

71


can be said. A suitable notion of “simply-typed” programs is needed, such as thatprovided by Griffin (1990) for λK. The type-based expansion algorithm of Fig-ure 4.4 applies without modification and lemma 8 holds, allowing 0CFA for thisclass of programs to be done in LOGSPACE. Linear logic provides a foundationfor (classical) λ-calculi with control; related logical insights allow control flowanalysis in this setting.

The graph coding of terms in our development is based on the technology of shar-ing graphs in the untyped case, and proof nets in the typed case (Lafont 1995).The technology of proofnets have previously been extended to intersection types(Regnier 1992; Møller Neergaard 2004), which have a close connection to flowanalysis (Amtoft and Turbak 2000; Palsberg and Pavlopoulou 2001; Wells et al.2002; Banerjee and Jensen 2003).

The graph codings, CFA graphs, and virtual wire propagation rules share a strongresemblance to the “pre-flow” graphs, flow graphs, and graph “closing rules”,respectively, of Mossin (1997b). Casting the analysis in this light leads to insightsfrom linear logic and optimal reduction. For example, as Mossin (1997b, page 78)notes, the CFA virtual paths computed by 0CFA are an approximation of the actualrun-time paths and correspond exactly to the “well-balanced paths” of Asperti andLaneve (1995) as an approximation to “legal paths” (Levy 1978) and results onproof normalization in linear logic (Mairson and Terui 2003) informed the novelflow analysis algorithms presented here.

72

Chapter 5

kCFA and EXPTIME

In this chapter, we give an exact characterization of the computational complexityof the kCFA hierarchy. For any k > 0, we prove that the control flow decisionproblem is complete for deterministic exponential time. This theorem validatesempirical observations that such control flow analysis is intractable. It also pro-vides more general insight into the complexity of abstract interpretation.

5.1 Shivers’ kCFA

As noted in section 1.1, practical flow analyses must negotiate a compromise be-tween complexity and precision, and their expressiveness can be characterized bythe computational resources required to compute their results.

Examples of simple yet useful flow analyses include Shivers’ 0CFA (1988) andHenglein’s simple closure analysis (1992), which are monovariant—functionsthat are closed over the same λ-expression are identified. Their expressivenessis characterized by the class PTIME (chapter 3).

As described in chapter 3, a monovariant analysis is one that approximates atpoints of nonlinearity. When a variable appears multiple times, flow informationis merged together for all sites.

So for example, in analyzing the program from section 3.2,

(λf.(ff)(λy.y))(λx.x),

73

CHAPTER 5. KCFA AND EXPTIME

a monovariant analysis such as 0CFA or simple closure analysis will merge theflow information for the two occurrences of f . Consequently both λx.x and λy.yare deemed to flow out of the whole expression.

More precise analyses can be obtained by incorporating context-sensitivity to dis-tinguish multiple closures over the same λ-term, resulting in “finer grained ap-proximations, expending more work to gain more information” (Shivers 1988,1991). This context-sensitivity will allow the two occurrences of f to be analyzedindependently. Consequently, such an analysis will determine that only λy.y flowsout of the expression.

To put it another way, a context-sensitive analysis is capable of evaluating thisprogram.

As a first approximation to understanding, the added precision of kCFA can bethought of as the ability to do partial reductions before analysis. If were to first re-duce all of the apparent redexes in the program, and then do 0CFA on the residual,our example program would look like

(λx1.x1)(λx2.x2)(λy.y).

Being a linear program, 0CFA is sufficient to prove only λy.y flows out of thisresidual. The polyvariance of kCFA is powerful enough to prove the same, how-ever it is important to note that it is not done by a bounded reduction of the pro-gram. Instead, the kCFA hierarchy uses the last k calling contexts to distinguishclosures.

The increased precision comes with an empirically observed increase in cost. AsShivers noted in his retrospective on the kCFA work (2004):

It did not take long to discover that the basic analysis, for any k > 0,was intractably slow for large programs. In the ensuing years, re-searchers have expended a great deal of effort deriving clever ways totame the cost of the analysis.

A fairly straightforward calculation—see, for example, Nielson et al. (1999)—shows that 0CFA can be computed in polynomial time, and for any k > 0, kCFAcan be computed in exponential time.

These naive upper bounds suggest that the kCFA hierarchy is essentially flat; re-

74


searchers subsequently “expended a great deal of effort” trying to improve them.1

For example, it seemed plausible (at least, to us) that the kCFA problem could bein NPTIME by guessing flows appropriately during analysis.

As this dissertation shows, the naive algorithm is essentially the best one, and thelower bounds are what needed improving. We prove that for all k > 0, computingthe kCFA analysis requires (and is thus complete for) deterministic exponentialtime. There is, in the worst case—and plausibly, in practice—no way to tame thecost of the analysis. Exponential time is required.

Why should this result matter to functional programmers?

• This result concerns a fundamental and ubiquitous static analysis of func-tional programs.

The theorem gives an analytic, scientific characterization of the expressivepower of kCFA. As a consequence, the empirically observed intractabilityof the cost of this analysis can be understood as being inherent in the ap-proximation problem being solved, rather than reflecting unfortunate gapsin our programming abilities.

Good science depends on having relevant theoretical understandings of whatwe observe empirically in practice.

This connection between theory and experience contrasts with the similarresult for ML-type inference (Mairson 1990): while the problem of rec-ognizing ML-typable terms is complete for exponential time, programmershave happily gone on programming. It is likely that their need of higher-order procedures, essential for the lower bound, is not considerable.2

But static flow analysis really has been costly, and this theorem explainswhy.

• The theorem is proved by functional programming.

We take the view that the analysis itself is a functional programming lan-guage, albeit with implicit bounds on the available computational resources.

1Even so, there is a big difference between algorithms that run in 2n and 2n2

steps, though bothare nominally in EXPTIME.

2Kuan and MacQueen (2007) have recently provided a refined perspective on the complexity ofML-type inference that explains why it works so quickly in practice.

75


Our result harnesses the approximation inherent in kCFA as a computationaltool to hack exponential time Turing machines within this unconventionallanguage. The hack used here is completely unlike the one used for the MLanalysis, which depended on complete developments of let-redexes. Thetheorem we prove in this paper uses approximation in a way that has littleto do with normalization.

We proceed by first bounding the complexity of kCFA from above, showing thatkCFA can be solved in exponential time (section 5.2). This is easy to calculateand is known (Nielson et al. 1999). Next, we bound the complexity from be-low by using kCFA as a SAT-solver. This shows kCFA is at least NPTIME-hard(section 5.3). The intuitions developed in the NPTIME-hardness proof can be im-proved to construct a kind of exponential iterator. A small, elucidative example isdeveloped in section 5.4. These ideas are then scaled up and applied in section 5.5to close the gap between the EXPTIME upper bound and NPTIME lower bound bygiving a construction to simulate Turing machines for an exponential number ofsteps using kCFA, thus showing kCFA to be complete for EXPTIME.

5.2 kCFA is in EXPTIME

Recall the definition of kCFA from section 2.3. The cache, C, r, is a finite mappingand has nk+1 entries. Each entry contains a set of closures. The environmentcomponent of each closure maps p free variables to any one of nk contours. Thereare n possible λ-terms and nkp environments, so each entry contains at most n1+kp

closures. Analysis is monotonic, and there are at most n1+(k+1)p updates to thecache. Since p ≤ n, we conclude:

Lemma 10. The control flow problem for kCFA is contained in EXPTIME.

It is worth noting that this result shows, from a complexity perspective, the flatnessof the kCFA hierarchy: for any constant k, kCFA is decidable in exponential time.It is not the case, for example, that 1CFA requires exponential time (for all j,DTIME(2n

j) ⊆ EXPTIME), while 2CFA requires doubly exponential time (for all j,

DTIME(22nj

) ⊆ 2EXPTIME), 3CFA requires triply exponential time, etc. There arestrict separation results for these classes, EXPTIME ⊂ 2EXPTIME ⊂ 3EXPTIME,etc., so we know from the above lemma there is no need to go searching for lowerbounds greater than EXPTIME.

76


5.3 kCFA is NPTIME-hard

Because kCFA makes approximations, many closures can flow to a single programpoint and contour. In 1CFA, for example, λw.wx1x2 · · ·xn has n free variables,with an exponential number of possible associated environments mapping thesevariables to program points (contours of length 1). Approximation allows us tobind each xi, independently, to either of the closed λ-terms for True or Falsethat we saw in the PTIME-completeness proof for 0CFA. In turn, application toan n-ary Boolean function necessitates computation of all 2n such bindings inorder to compute the flow out from the application site. The term True canonly flow out if the Boolean function is satisfiable by some truth valuation. For

(λf1.(f1 True)(f1 False))

(λx1.


(λx2.


(λx3.

· · ·(λfn.(fn True)(fn False))

(λxn.

C[(λv.φ v)(λw.wx1x2 · · · xn)]) · · ·))))

Figure 5.1: NPTIME-hard construction for kCFA.

an appropriately chosen program point (label) `, the cache location C(v, `) willcontain the set of all possible closures which are approximated to flow to v. Thisset is that of all closures

〈(λw.wx1x2 · · ·xn), ρ〉

where ρ ranges over all assignments of True and False to the free variables(or more precisely assignments of locations in the table containing True andFalse to the free variables). The Boolean function φ is completely linear, as inthe PTIME-completeness proof; the context C uses the Boolean output(s) as in theconclusion to that proof: mixing in some ML, the context is:

77


- let val (u,u’)= [---] inlet val ((x,y),(x’,y’))= (u (f,g), u’ (f’,g’)) in

((x a, y b),(x’ a’, y’ b’)) end end;

Again, a can only flow as an argument to f if True flows to (u,u’), leaving(f,g) unchanged, which can only happen if some closure 〈(λw.wx1x2 · · ·xn), ρ〉provides a satisfying truth valuation for φ. We have as a consequence:

Theorem 8. The control flow problem for 1CFA is NPTIME-hard.

Having established this lower bound for 1CFA, we now argue the result general-izes to all values of k > 0. Observe that by going from kCFA to (k + 1)CFA,further context-sensitivity is introduced. But, this added precision can be undoneby inserting an identity function application at the point relevant to answering theflow question. This added calling context consumes the added bit of precision inthe analysis and renders the analysis of rest of the program equivalently to thecourser analysis. Thus, it is easy to insert an identity function into the above con-struction such that 2CFA on this program produces the same results as 1CFA onthe original. So for any k > 1, we can construct an NPTIME-hard computation byfollowing the above construction and inserting k−1 application sites to eat up theprecision added beyond 1CFA. The result is equivalent to 1CFA on the originalterm, so we conclude:

Theorem 9. The control flow problem for kCFA is NPTIME-hard, for any k > 0.

At this point, there is a tension in the results. On the one hand, kCFA is containedin EXPTIME; on the other, kCFA requires at least NPTIME-time to compute. Soa gap remains; either the algorithm for computing kCFA can be improved andput into NPTIME, or the lower bound can be strengthened by exploiting morecomputational power from the analysis.

We observe that while the computation of the entire cache requires exponentialtime, perhaps the existence of a specific flow in it may well be computable inNPTIME. A non-deterministic algorithm might compute using the “collection se-mantics” EJt`Kρδ , but rather than compute entire sets, choose the element of the setthat bears witness to the flow. If so we could conclude kCFA is NPTIME-complete.

However, this is not the case. We show that the lower bound can be improvedand kCFA is complete for EXPTIME. The improvement relies on simulating anexponential iterator using analysis. The following section demonstrates the coreof the idea.

78


5.4 Nonlinearity and Cartesian Products:a toy calculation, with insights

A good proof has, at its heart, a small and simple idea that makes it work. Forour proof, the key idea is how the approximation of analysis can be leveragedto provide computing power above and beyond that provided by evaluation. Thedifference between the two can be illustrated by the following term:

(λf.(f True)(f False))(λx.Impliesx x)

Consider evaluation: Here Impliesx x (a tautology) is evaluated twice, oncewith x bound to True, once with x bound to False. But in both cases, theresult is True. Since x is bound to True or False both occurrences of x arebound to True or to False—but it is never the case, for example, that the firstoccurrence is bound to True, while the second is bound to False. The valuesof each occurrence of x is dependent on the other.

On the other hand, consider what flows out of Impliesx x according 1CFA:both True and False. Why? The approximation incurs analysis of Impliesx xfor x bound to True and False, but it considers each occurrence of x as rangingover True and False, independently. In other words, for the set of values boundto x, we consider their cross product when x appears nonlinearly. The approxi-mation permits one occurrence of x be bound to True while the other occurrenceis bound to False; and somewhat alarmingly, ImpliesTrueFalse causesFalse to flow out. Unlike in normal evaluation, where within a given scope weknow that multiple occurrences of the same variable refer to the same value, in theapproximation of analysis, multiple occurrences of the same variable range overall values that they are possible bound to independent of each other.

Now consider what happens when the program is expanded as follows:

(λf.(f True)(f False))(λx.(λp.p(λu.p(λv.Impliesuv)))(λw.wx))

Here, rather than pass x directly to Implies, we construct a unary tuple λw.wx.The tuple is used nonlinearly, so pwill range over closures of λw.wxwith x boundto True and False, again, independently.

A closure can be approximated by an exponential number of values. For exam-ple, λw.wz1z2 . . . zn has n free variables, so there are an exponential number of

79


possible environments mapping these variables to program points (contours oflength 1). If we could apply a Boolean function to this tuple, we would effectivelybe evaluating all rows of a truth table; following this intuition leads to NPTIME-hardness of the 1CFA control flow problem.

Generalizing from unary to n-ary tuples in the above example, an exponentialnumber of closures can flow out of the tuple. For a function taking two n-tuples,we can compute the function on the cross product of the exponential number ofclosures.

This insight is the key computational ingredient in simulating exponential time,as we describe in the following section.

5.5 kCFA is EXPTIME-hard

5.5.1 Approximation and EXPTIME

Recall the formal definition of a Turing machine: a 7-tuple

〈Q,Σ,Γ, δ, q0, qa, qr〉

where Q, Σ, and Γ are finite sets, Q is the set of machine states (and {q0, qa, qr} ⊆Q), Σ is the input alphabet, and Γ the tape alphabet, where Σ ⊆ Γ. The statesq0, qa, and qr are the machine’s initial, accept, and reject states, respectively. Thecomplexity class EXPTIME denotes the languages that can be decided by a Turingmachine in time exponential in the input length.

Suppose we have a deterministic Turing machine M that accepts or rejects itsinput x in time 2p(n), where p is a polynomial and n = |x|. We want to simulatethe computation ofM on x by kCFA analysis of a λ-termE dependent onM,x, p,where a particular closure will flow to a specific program point iff M accepts x.It turns out that k = 1 suffices to carry out this simulation. The construction,computed in logarithmic space, is similar for all constant k > 1 modulo a certainamount of padding as described in section 5.3.

80


5.5.2 Coding Machine IDs

The first task is to code machine IDs. Observe that each value stored in the ab-stract cache C is a closure—a λ-abstraction, together with an environment for itsfree variables. The number of such abstractions is bounded by the program size,as is the domain of the environment—while the number of such environments isexponential in the program size. (Just consider a program of size n with, say, n/2free variables mapped to only 2 program points denoting bindings.)

Since a closure only has polynomial size, and a Turing machine ID has exponentialsize, we represent the latter by splitting its information into an exponential numberof closures. Each closure represents a tuple 〈T, S,H,C, b〉, which can be read as

“At time T , Turing machine M was in state S, the tape position wasat cell H , and cell C held contents b.”

T , S, H , and C are blocks of bits (0 ≡ True, 1 ≡ False) of size polynomial inthe input to the Turing machine. As such, each block can represent an exponentialnumber of values. A single machine ID is represented by an exponential numberof tuples (varying C and b). Each such tuple can in turn be coded as a λ-termλw.wz1z2 · · · zN , where N = O(p(n)).

We still need to be able to generate an exponential number of closures for suchan N -ary tuple. The construction is only a modest, iterative generalization of theconstruction in our toy calculation above:

(λf1.(f1 0)(f1 1))(λz1.

(λf2.(f2 0)(f2 1))(λz2.· · ·

(λfN .(fN 0)(fN 1))(λzN .((λx.x)(λw.wz1z2 · · · zN))`) · · ·))

Figure 5.2: Generalization of toy calculation for kCFA.

In the inner subterm,((λx.x)(λw.wz1z2 · · · zN))`,

81


the function λx.x acts as a very important form of padding. Recall that this iskCFA with k = 1—the expression (λw.wz1z2 · · · zN) is evaluated an exponen-tial number of times—to see why, normalize the term—but in each instance, thecontour is always `. (For k > 1, we would just need more padding to evade thepolyvariance of the flow analyzer.) As a consequence, each of the (exponentialnumber of) closures gets put in the same location of the abstract cache C, whilethey are placed in unique, different locations of the exact cache C. In other words,the approximation mechanism of kCFA treats them as if they are all the same.(That is why they are put in the same cache location.)

5.5.3 Transition Function

Now we define a binary transition function δ, which does a piecemeal transitionof the machine ID. The transition function is represented by three rules, identifieduniquely by the time stamps T on the input tuples.

The first transition rule is used when the tuples agree on the time stamp T , andthe head and cell address of the first tuple coincide:

δ〈T, S,H,H, b〉〈T, S ′, H ′, C ′, b′〉 =〈T + 1, δQ(S, b), δLR(S,H, b), H, δΣ(S, b)〉

This rule computes the transition to the next ID. The first tuple has the head ad-dress and cell address coinciding, so it has all the information needed to computethe next state, head movement, and what to write in that tape cell. The secondtuple just marks that this is an instance of the computation rule, simply indicatedby having the time stamps in the tuples to be identical. The Boolean functionsδQ, δLR, δΣ compute the next state, head position, and what to write on the tape.

The second communication rule is used when the tuples have time stamps T + 1and T : in other words, the first tuple has information about state and head positionwhich needs to be communicated to every tuple with time stamp T holding tapecell information for an arbitrary such cell, as it gets updated to time stamp T + 1:

δ〈T + 1, S,H,C, b〉〈T, S ′, H ′, C ′, b′〉 = 〈T + 1, S,H,C ′, b′〉(H ′ 6= C ′)

(Note that when H ′ = C ′, we have already written the salient tuple using thetransition rule.) This rule communicates state and head position (for the first tuple

82


computed with time stamp T + 1, where the head and cell address coincided) toall the other tuples coding the rest of the Turing machine tape.

Finally, we define a catch-all rule, mapping any other pairs of tuples (say, withtime stamps T and T + 42) to some distinguished null value (say, the initial ID).We need this rule just to make sure that δ is a totally defined function.

δ〈T, S,H,C, b〉〈T ′, S ′, H ′, C ′, b′〉 = Null(T 6= T ′ and T 6= T ′ + 1)

Clearly, these three rules can be coded by a single Boolean circuit, and we haveall the required Boolean logic at our disposal from section 3.5.

Because δ is a binary function, we need to compute a cross product on the cod-ing of IDs to provide its input. The transition function is therefore defined as inFigure 5.3. The Copy functions just copy enough of the input for the separate cal-

Φ ≡ λp.let 〈u1, u2, u3, u4, u5〉 = Copy5 p inlet 〈v1, v2, v3.v4, v5〉 = Copy5 p in

(λw.w(φTu1v1)(φSu2v2) . . . (φbu5v5))(λwT .λwS.λwH .λwC .λwb.wT (λz1.λz2 . . . λzT .wS(λzT+1.λzT+2 . . . λzT+S.. . .wb(λzC+1.λzC+2 . . . λzC+b=m.λw.wz1z2 . . . zm) . . .)))

Figure 5.3: Turing machine transition function construction.

culations to be implemented in a linear way. Observe that this λ-term is entirelylinear except for the two occurrences of its parameter p. In that sense, it servesa function analogous to λx.Impliesx x in the toy calculation. Just as x rangesthere over the closures for True and for False, p ranges over all possible IDsflowing to the argument position. Since there are two occurrences of p, we havetwo entirely separate iterations in the kCFA analysis. These separate iterations,like nested “for” loops, create the equivalent of a cross product of IDs in the “innerloop” of the flow analysis.

83


C ≡ (λf1.(f1 0)(f1 1))(λz1.

(λf2.(f2 0)(f2 1))(λz2.· · ·

(λfN .(fN 0)(fN 1))(λzN .((λx.x)(Widget(Extract[ ]))`)`

′) · · ·))

Figure 5.4: EXPTIME-hard construction for kCFA.

5.5.4 Context and Widget

The context for the Turing machine simulation needs to set up the initial ID andassociated machinery, extract the Boolean value telling whether the machine ac-cepted its input, and feed it into the flow widget that causes different flows de-pending on whether the value flowing in is True or False. In this code, theλx.x (with label `′ on its application) serve as padding, so that the term within isalways applied in the same contour. Extract extracts a final ID, with its timestamp, and checks if it codes an accepting state, returning True or False ac-cordingly. Widget is our standard control flow test. The context is instantiatedwith the coding of the transition function, iterated over an initial machine ID,

2n Φ λw.w0 . . .0 · · ·Q0 · · ·H0 · · · z1z2 . . . zN0,

where Φ is a coding of transition function for M . The λ-term 2n is a fixed pointoperator for kCFA, which can be assumed to be either Y, or an exponential func-tion composer. There just has to be enough iteration of the transition function toproduce a fixed point for the flow analysis.

To make the coding easy, we just assume without loss of generality that M startsby writing x on the tape, and then begins the generic exponential-time computa-tion. Then we can just have all zeroes on the initial tape configuration.

Lemma 11. For any Turing machineM and input x of length n, whereM acceptsor rejects x in 2p(n) steps, there exists a logspace-constructable, closed, labeledλ-term e with distinguished label ` such that in the kCFA analysis of e (k > 0),True flows into ` iff M accepts x.

84


Theorem 10. The control flow problem for kCFA is complete for EXPTIME forany k > 0.

5.6 Exact kCFA is PTIME-complete

At the heart of the EXPTIME-completeness result is the idea that the approximationinherent in abstract interpretation is being harnessed for computational power,quite apart from the power of exact evaluation. To get a good lower bound, thisis necessary: it turns out there is a dearth of computation power when kCFAcorresponds with evaluation, i.e. when the analysis is exact.

As noted earlier, approximation arises from the truncation of contours during anal-ysis. Consequently, if truncation never occurs, the instrumented interpreter andthe abstract interpreter produce identical results for the given program. But whatcan we say about the complexity of these programs? In other words, what kindof computations can kCFA analyze exactly when k is a constant, independent ofthe program analyzed? What is the intersection between the abstract and concreteinterpreter?

An answer to this question provides another point in the characterization of theexpressiveness of an analysis. For 0CFA, the answer is PTIME since the evaluationof linear terms is captured. For kCFA, the answer remains the same.

For any fixed k, kCFA can only analyze polynomial time programs exactly, since,in order for an analysis to be exact, there can only one entry in each cache location,and there are only nk+1 locations. But from this it is clear that only throughthe use of approximation that a exponential time computation can be simulated,but this computation has little to do with the actual running of the program. Aprogram that runs for exponential time cannot be analyzed exactly by kCFA forany constant k.

Contrast this with ML-typability, for example, where the evaluation of programsthat run for exponential time can be simulated via type inference.

Note that if the contour is never truncated, every program point is now approx-imated by at most one closure (rather than an exponential number of closures).The size of the cache is then bounded by a polynomial in n; since the cache iscomputed monotonically, the analysis and the natural related decision problem is

85


constrained by the size and use of the cache.

Proposition 1. Deciding the control flow problem for exact kCFA is complete forPTIME.

This proposition provides a characterization of the computational complexity (orexpressivity) of the language evaluated by the instrumented evaluator E of sectionsection 2.2 as a function of the contour length.

It also provides an analytic understanding of the empirical observation researchershave made: computing a more precise analysis is often cheaper than performinga less precise one, which “yields coarser approximations, and thus induces moremerging. More merging leads to more propagation, which in turn leads to morereevaluation” (Wright and Jagannathan 1998). Might and Shivers (2006b) make asimilar observation: “imprecision reinforces itself during a flow analysis throughan ever-worsening feedback loop.” This ever-worsening feedback loop, in whichwe can make False (spuriously) flow out of Impliesx x, is the critical ingre-dient in our EXPTIME lower bound.

Finally, the asymptotic differential between the complexity of exact and abstractinterpretation shows that abstract interpretation is strictly more expressive, for anyfixed k.

5.7 Discussions

We observe an “exponential jump” between contour length and complexity ofthe control flow decision problem for every polynomial-length contour, includingcontours of constant length. Once k = n (contour length equals program size), anexponential-time hardness result can be proved which is essentially a linear circuitwith an exponential iterator—very much like Mairson (1990). When the contoursare exponential in program length, the decision problem is doubly exponential,and so on.

The reason for this exponential jump is the cardinality of environments in closures.This, in fact, is the bottleneck for control flow analysis—it is the reason that 0CFA(without closures) is tractable, while 1CFA is not. If f(n) is the contour lengthand n is the program length, then

|CEnv| = |Var→ ∆≤f(n)| = (nf(n))n = 2f(n)n lgn

86


This cardinality of environments effectively determines the size of the universe ofvalues for the abstract interpretation realized by CFA.

When k is a constant, one might ask why the inherent complexity is exponentialtime, and not more—especially since one can iterate (in an untyped world) withthe Y combinator. Exponential time is the “limit” because with a polynomial-length tuple (as constrained by a logspace reduction), you can only code an expo-nential number of closures.

The idea behind kCFA is that the precision of could dialed up, but there are es-sentially two settings to the kCFA hierarchy: high (k > 0, EXPTIME) and low(k = 0). We can see, from a computational complexity perspective, that 0CFAis strictly less expressive than kCFA. In turn, kCFA is strictly less expressivethan, for example, Mossin’s flow analysis (1997a). Mossin’s analysis is a strongeranalysis in the sense that it is exact for a larger class of programs than 0CFA orkCFA—it exact not only for linear terms, but for all simply-typed terms. In otherwords, the flow analysis of simply-typed programs is synonymous with runningthe program, and hence non-elementary. This kind of expressivity is also found inBurn-Hankin-Abramsky-style strictness analysis (1985). But there is a consider-able gap between kCFA and these more expressive analyses. What is in betweenand how can we build a real hierarchy of static analyses that occupy positionswithin this gap?

This argues that the relationship between dial level N and N + 1 should be exact.This is the case with say simple-typing and ML-typing. (ML = simple + let re-duction). There is no analogous relationship known between k and k + 1CFA. Amajor computational expense in kCFA is the approximation engendering furtherapproximation and re-evaluation. Perhaps by staging analysis into polyvarianceand approximation phases, the feedback loop of spurious flows can be avoided.

If you had an analysis that did some kind of exact, bounded, evaluation of theprogram and then analyzed the residual with 0CFA, you may have a far moreusable analysis than with the kCFA hierarchy.

The precision of kCFA is highly sensitive to syntactic structure. Simple programrefactorings such as η-expansion have drastic effects on the results of kCFA andcan easily undermine the added work of a more and more precise analysis. Indeed,we utilize these simple refactorings to undermine the added precision of kCFA togeneralize the hardness results from the case of 1CFA to all k > 0 CFA. But ananalysis that was robust in the face of these refactorings could undermine these

87


lower bounds.

In general, techniques that lead to increased precision will take computationalpower away from our lower bound constructions. For instance, it is not clear whatcould be said about lower bounds on the complexity of a variant of kCFA thatemployed abstract garbage collection (Might and Shivers 2006b), which allowsfor the safe removal of values from the cache during computation. It is critical inthe lower bound construction that what goes into the cache, stays in the cache.

Levy’s notion of labeled reduction (1978; 1980) provides a richer notion of “in-strumented evaluation” coupled with a richer theory of exact flow analysis, namelythe geometry of interaction (Girard 1989; Gonthier et al. 1992). With the propernotion of abstraction and simulated reduction, we should be able to design morepowerful flow analyses, filling out the hierarchy from 0CFA up to the expressivityof Mossin’s analysis in the limit.

5.8 Conclusions

Empirically observed increases in costs can be understood analytically as inherentin the approximation problem being solved.

We have given an exact characterization of the kCFA approximation problem. TheEXPTIME lower bound validates empirical observations and shows that there is notractable algorithm for kCFA.

The proof relies on previous insights about linearity, static analysis, and normal-ization (namely, when a term is linear, static analysis and normalization are syn-onymous); coupled with new insights about using nonlinearity to realize the fullcomputational power of approximate, or abstract, interpretation.

Shivers wrote in his best of PLDI retrospective (2004),

Despite all this work on formalising CFA and speeding it up, I havebeen disappointed in the dearth of work extending its power.

This work has shown that work spent on speeding up kCFA is an exercise in futil-ity; there is no getting around the exponential bottleneck of kCFA. The one-worddescription of the bottleneck is closures, which do not exist in 0CFA, because free

88


variables in a closure would necessarily map to ε, and hence the environments areuseless.

This detailed accounting of the ingredients that combine to make kCFA hard,when k > 0, should provide guidance in designing new abstractions that avoidcomputationally expensive components of analysis. A lesson learned has beenthat closures, as they exist when k > 0, result in an exponential value space thatcan be harnessed for the EXPTIME lower-bound construction.

89

Chapter 6

Related Work

This dissertation draws upon several large veins of research. At the highest level,this includes complexity, semantics, logic, and program analysis. This chaptersurveys related work to sketch applications and draw parallels with existing work.

6.1 Monovariant Flow Analysis

In the setting of first-order programming languages, Reps (1996) gives a com-plexity investigation of program analyses and shows interprocedural slicing tobe complete for PTIME and that obtaining “meet-over-all-valid-paths” solutionsof distributive data-flow analysis problems (Hecht 1977) is PTIME-hard in gen-eral, and PTIME-complete when there are only a finite number of data-flow facts.A circuit-value construction by interprocedural data-flow analysis is given usingBoolean circuitry encoded as call graph gadgets, similar in spirit to our construc-tions in chapter 3.

In the setting of higher-order programming languages, Melski and Reps (2000)give a complexity investigation of 0CFA-like, inclusion-based monovariant flowanalysis for a functional language with pattern matching. The analysis takes theform of a constraint satisfaction problem and this satisfaction problem is shownto be complete for PTIME. See section 6.3 for further discussion.

The impact of pattern matching on analysis complexity is further examined byHeintze and McAllester (1997b), which shows how deep pattern matching affects

91

CHAPTER 6. RELATED WORK

monovariant analysis, making it complete for EXPTIME.

6.2 Linearity and Static Analysis

Jagannathan et al. (1998) observe that flow analysis, which is a may analysis, canbe adapted to answer must analysis questions by incorporating a “per-program-point variable cardinality map, which indicates whether all reachable environ-ments binding a variable x hold the same value. If so, x is marked single atthat point; otherwise x is marked multiple.” The resulting must-alias informationfacilities program optimization such as lightweight closure conversion (Stecklerand Wand 1997). This must analysis is a simple instance of tracking linearity in-formation in order to increase the precision of the analysis. Might and Shivers(2006b) use a similar approach of abstract counting, which distinguish singletonand non-singleton flow sets, to improve flow analysis precision.

Something similar can be observed in 0CFA without cardinality maps; singletonflow sets C(`) = {λx.e}, which are interpreted as “the expression labelled ` mayevaluate to one of {λx.e},” convey must information. The expression labelled` either diverges or evaluates to λx.e. When λx.e is linearly closed—the vari-ables map to singleton sets containing linear closures—then the run-time valueproduced by the expression labelled ` can be determined completely at analysistime. The idea of taking this special case of must analysis within a may analysisto its logical conclusion is the basis of chapter 3.

Damian and Danvy (2003) have investigated the impact of linear β-reduction onthe result of flow analysis and show how leastness is preserved. The result is usedto show that leastness is preserved through CPS and administrative reductions,which are linear.

An old, but key, observation about the type inference problem for simply typed λ-terms is that, when the term is linear (every bound variable occurs exactly once),the most general type and normal form are isomorphic (Hindley 1989; Hirokawa1991; Henglein and Mairson 1991; Mairson 2004).1

The observation translates to flow analysis, as shown in chapter 3, but in a typed

1The seed of inspiration for this work came from a close study of Mairson (2004) in the Springof 2005 for a seminar presentation given in a graduate course on advanced topics in complexitytheory at the University of Vermont.

92


setting, it also scales to richer systems. The insight leads to an elegant reproof ofthe EXPTIME-hardness of ML-type inference result from Mairson (1990) (Hen-glein 1990). It was used to prove novel lower bounds on type inference for Sys-tem Fω (Henglein and Mairson 1991) and rank-bound intersection type inference(Møller Neergaard and Mairson 2004). See section 6.10 for further discussion.

6.3 Context-Free-Language Reachability

Melski and Reps (2000) show the interconvertibility between a number of set-constraint problems and the context-free-language (CFL) reachability problem,which is known to be complete for PTIME (Ullman and van Gelder 1986). Heintze(1994) develops a set-based approach to flow analysis for a simple untyped func-tional language with functions, applications, pattern-matching, and recursion. Theanalysis works by making a pass over the program, generating set constraints,which can then be solved to compute flow analysis results. Following Melski andReps, we refer to this constraint system as ML set-constraints. For the subset ofthe language considered in this dissertation, solving these constraints computes amonovariant flow analysis that coincides with 0CFA.

In addition to the many set-constraint problems considered, which have applica-tions to static analysis of first-order programming languages, Melski and Reps(2000, section 5) also investigate the problem of solving the ML set-constraintsused by Heintze. They show this class of set-constraint problems can be solvedin cubic time with respect to the size of the input constraints. Since Heintze(1994) gave a O(n3) algorithm for solving these constraints, Melski and Reps’ re-sult demonstrates the conversion to CFL-reachability preserves cubic-solvability,while allowing CFL-reachability formulations of static analyses, such as programslicing and shape analysis, to be brought to bear on higher-order languages, wherepreviously they had only been applied in a first-order setting.

After showing ML set-constraints can be solved using CFL-reachability, Mel-ski and Reps (2000, section 6) also prove the converse holds: CFL-reachabilityproblems can be solved by reduction to ML set-constraint problems while pre-serving the worse-case asymptotic complexity. By the known PTIME-hardness ofCFL-reachability, this implies ML set-constraint satisfaction is PTIME-complete.It does not follow, however, that 0CFA is also PTIME-complete.

93


It is worth noting that Melski and Reps are concerned with constraint satisfaction,and not directly with flow analysis—the two are intimately related, but the dis-tinction is important. It follows as a corollary that since ML set-constraints can besolved, through a reduction to CFL-reachability, flow analysis can be performed incubic time. Heintze (1994, page 314) observes that the size of the set-constraintproblem generated by the initial pass of the program is linear in the size of theprogram being analyzed. Therefore it is straightforward to derive from the MLset-constraint to CFL-reachability reduction the (known) inclusion of 0CFA inPTIME.

In the other direction, it is not clear that it follows from the PTIME-hardness ofML set-constraint satisfaction that flow analysis of Heintze’s subject language isPTIME-hard. Melski and Reps use the constraint language directly in their encod-ing of CFL-reachability. What remains to be seen is whether there are programswhich could be constructed that would induce these constraints. Moreover, theirreduction relies soley on the “case” constraints of Heintze, which are set con-straints induced by pattern matching expressions in the source language.

If the source language lacks pattern matching, the Boolean circuit machinery ofMelski and Reps can no longer be constructed since no expressions induce theneeded “case” constraints. For this language, the PTIME-hardness of constraintsatisfaction and 0CFA does not follow from the results of Melski and Reps.

This reiterates the importance of Reps’ own observation that analysis problemsshould be formulated in “trimmed-down form,” which both leads to a wider ap-plicability of the lower bounds and “allows one to gain greater insight into exactlywhat aspects of an [. . . ] analysis problem introduce what computational limita-tions on algorithms for these problems,” (Reps 1996, section 2).

By considering only the core subset of every higher-order programming languageand relying on the specification of analysis, rather than its implementation tech-nology, the 0CFA PTIME-completeness result implies as an immediate corollarythe PTIME-completeness of the ML set-constraint problem considered by Melskiand Reps. Moreover, as we have seen, our proof technique of using linearity tosubvert approximation is broadly applicable to further analysis approximations,whereas CFL-reachability reductions must be replayed mutatis mutandis.

94


6.4 2NPDA and the Cubic Bottleneck

The class 2NPDA contains all languages that are recognizable by a two-way non-deterministic push-down automaton.2 The familiar PDAs found in undergraduatetextbooks (Martin 1997), both deterministic and non-deterministic, are one-way:consuming their input from left-to-right. In contrast, two-way NPDAs accept theirinput on a read-only input tape marked with special begin and end markers, onwhich they can move the read-head forwards, backwards, or not at all.

Over a decade ago, Heintze and McAllester (1997c) proved deciding a monovari-ant flow analysis problem to be at least as hard as 2NPDA, and argued this providedevidence the “cubic bottleneck” of flow analysis was unlikely to be overcomesince the best known algorithm for 2NPDA was cubic and had not been improvedsince its formulation by Aho et al. (1968). This statement was made by severalother papers (Neal 1989; Heintze and McAllester 1997c,a; Melski and Reps 2000;McAllester 2002; Van Horn and Mairson 2008b). Yet collectively, this is simplyan oversight in the history of events; Rytter (1985) improved the cubic bound bya logarithmic factor.

Since then, Rytter’s technique has been used in various contexts: in diameterverification, in Boolean matrix multiplication, and for the all pairs shortest pathsproblem (Basch et al. 1995; Zwick 2006; Chan 2007), as well as for reachability inrecursive state machines (Chaudhuri 2008), and for maximum node-weighted k-clique (Vassilevska 2009) to name a few. In particular, Chaudhuri (2008) recentlyused Rytter’s techniques to formulate a subcubic algorithm for the related problemof context-free language (CFL) reachability. Perhaps unknown to most, indirectlythis constitutes the first subcubic inclusion-based flow analysis algorithm whencombined with a reduction due to Melski and Reps (2000).

The logarithmic improvement can be carried over to the flow analysis problemdirectly, by applying the same known set compression techniques Rytter (1985)applies to improve deciding 2NPDA. Moreover, refined analyses similar to Heintzeand McAllester (1997b) that incorporate notions of reachability to improve preci-sion remain subcubic. See Midtgaard and Van Horn (2009) for details.

0CFA is complete for both 2NPDA (Heintze and McAllester 1997c) and PTIME

(chapter 3). Yet, it is not clear what relation these class have to each other.

2This section is derived from material in Midtgaard and Van Horn (2009).

95


The 2NPDA inclusion proof of Heintze and McAllester is sensitive to representa-tion choices and problem formulations. They use an encoding of programs thatrequires a non-standard bit string labelling scheme in which identical subtermshave the same labels. The authors remark that without this labelling scheme, theproblem “appears not to be in 2NPDA.”

Moreover, the notions of reduction employed in the definitions of 2NPDA-hardnessand PTIME-hardness rely on different computational models. For a problem to be2NPDA-hard, all problems in the class must be reducible to it in O(nR(log n))time on a RAM, where R is a polynomial. Whereas for a problem to be PTIME-hard, all problems in the class must be reducible to it using a O(log n) spacework-tape on a Turing machine.

6.5 kCFA

Our coding of Turing machines is descended from work on Datalog (Prolog withvariables, but without constants or function symbols), a programming languagethat was of considerable interest to researchers in database theory during the1980s; see Hillebrand et al. (1995); Gaifman et al. (1993).

In kCFA and abstract interpretation more generally, an expression can evaluate toa set of values from a finite universe, clearly motivating the idiom of program-ming with sets. Relational database queries take as input a finite set of tuples,and compute new tuples from them; since the universe of tuples is finite and thecomputation is monotone, a fixed-point is reached in a finite number of iterations.The machine simulation here follows that framework very closely. Even the ideaof splitting a machine configuration among many tuples has its ancestor in Hille-brand et al. (1995), where a ternary cons(A,L,R) is used to simulate a cons-cellat memory address A, with pointers L,R. It needs emphasis that the computingwith sets described in this paper has little to do with normalization, and everythingto do with the approximation inherent in the abstract interpretation.

Although kCFA and ML-type inference are two static analyses complete for EX-PTIME (Mairson 1990), the proofs of these respective theorems is fundamentallydifferent. The ML proof relies on type inference simulating exact normalization(analogous to the PTIME-completeness proof for 0CFA), hence subverting the ap-proximation of the analysis. In contrast, the kCFA proof harnesses the approxi-

96


mation that results from nonlinearity.

6.6 Class Analysis

Flow analysis of functional languages is complicated by the fact that computa-tions are expressible values. This makes basic questions about control flow un-decidable in the general case. But the same is true in object-oriented programs—computations may be package up as values, passed as arguments, stored in data-structures, etc.—and so program analyses in object-oriented settings often dealwith the same issues as flow analysis. A close analogue of flow analysis is classanalysis.

Expressions in object-oriented languages may have a declared class (or type) but,at run-time, they can evaluate to objects of every subclass of the class. Classanalysis computes the actual set of classes that an expression can have at run-time (Johnson et al. 1988; Chambers and Ungar 1990; Palsberg and Schwartzbach1991; Bacon and Sweeney 1996). Class analysis is sometimes called receiverclass analysis, type analysis, or concrete type inference; it informs static methodresolution, inlining, and other program optimizations.

An object-oriented language is higher-order in the same way as a language withfirst-class functions and exactly the same circularity noted by Shivers occurs inthe class analysis of an object-oriented language.

Grove and Chambers (2001):

In object-oriented languages, the method invoked by a dynamicallydispatched message send depends on the class of the object receiv-ing the message; in languages with function values, the procedure in-voked by the application of a computed function value is determinedby the function value itself. In general, determining the flow of val-ues needed to build a useful call graph requires an interproceduraldata and control flow analysis of the program. But interproceduralanalysis in turn requires that a call graph be built prior to the analysisbeing performed.

Ten years earlier, Shivers (1991, page 6)3 had written essentially the same:3It is a testament to Shivers’ power as a writer that his original story has been told over and over

97


So, if we wish to have a control-flow graph for a piece of Schemecode, we need to answer the following question: for every procedurecall in the program, what are the possible lambda expressions thatcall could be a jump to? But this is a flow analysis question! So withregard to flow analysis in an HOL, we are faced with the followingunfortunate situation:

• In order to do flow analysis, we need a control-flow graph.

• In order to determine control-flow graphs, we need to do flowanalysis.

Class analysis is often presented using the terminology of type inference, howeverthese type systems typically more closely resemble flow analysis: types are finitesets of classes appearing syntactically in the program and subtyping is interpretedas set inclusion.

In other words, objects are treated much like functions in the flow analysis of afunctional language—typically both are approximated by a set of definition sites,i.e. an object is approximated by a set of class names that appear in the program;a function is approximated by a set of λ occurrences that appear in the program.In an object-oriented program, we may ask of a subexpression, what classes maythe subexpression evaluate to? In a functional language we may ask, what λ termsmay this expression evaluate to? Notice both are general questions that analysismust answer in a higher order setting if you want to know about control flow. Toknow where control may transfer to from (f x) we have to know what f maybe. To know where control may transfer to from f.apply(x) we have to knowwhat f may be. In both cases, if we approximate functions by sets of λs andobjects by sets of class names, we may determine a set of possible places in codewhere control may transfer, but we will not know about the environment of thiscode, i.e. the environment component of a closure or the record component of anobject.

Spoto and Jensen (2003) give a reformulation of several class analyses, includingthat of Palsberg and Schwartzbach (1991); Bacon and Sweeney (1996); Diwanet al. (1996), using abstract interpretation.

DeFouw et al. (1998) presents a number of variations on the theme of monovariantclass analysis. They develop a framework that can be instantiated to obtain inclu-

again in so many places, usually with half the style.

98


sion, equality, and optimistic based class analyses with close analogies to 0CFA,simple closure analysis, and rapid type analysis (Bacon and Sweeney 1996), re-spectively. Each of these instantiations enjoy the same asymptotic running timesas their functional language counterparts; cubic, near linear, and linear, respec-tively.

Although some papers give upper bounds for the algorithms they present, thereare very few lower bound results in the literature.4

Class analysis is closely related to points-to analysis in object-oriented languages.“Points-to analysis is a fundamental static analysis used by optimizing compilersand software engineering tools to determine the set of objects whose addressesmay be stored in reference variables and reference fields of objects,” (Milanovaet al. 2005). When a points-to analysis is flow-sensitive—“analyses take into ac-count the flow of control between program points inside a method, and computeseparate solutions for these points,” (Milanova et al. 2005)—the analysis neces-sarily involves some kind of class analysis.

In object-oriented languages, context-sensitive is typically distinguished as beingobject-sensitive (Milanova et al. 2005), call-site sensitive (Grove and Chambers2001), or partially flow sensitivity (Rinetzky et al. 2008).

Grove and Chambers (2001) provide a framework for a functional and object-oriented hybrid language that can be instantiated to obtain a kCFA analysis andan object-oriented analogue called k-l-CFA. There is a discussion and referencesin Section 9.1. In this discussion, Grove and Chambers (2001) cite Oxhøj et al.(1992) as giving “1-CFA extension to Palsberg and Schwartzbach’s algorithm,”although the paper develops the analysis as a type inference problem. Grove andChambers also cite Vitek et al. (1992) as one of several “adaptations of kCFA toobject-oriented programs,” and although this paper actually has analogies to kCFAin an object-oriented setting (they give a call-string approach to call graph contextsensitivity in section 7), it seems to be developed completely independently ofShivers’ kCFA work or any functional flow analysis work.

The construction of Figure 5.2 can be translated in an object-oriented languagesuch as Java, as given in Figure 6.1.5 Functions are simulated as objects withan apply method. The crucial subterm in Figure 6.1 is the construction of the list

4I was able to find zero papers that deal directly with lower bounds on class analysis complexity.5This translation is Java except for the made up list constructor and some abbreviation in typenames for brevity, i.e. B is shorthand for Boolean.

99


new Fun<Fun<B,List>,List>() {public List apply(Fun<B,List> f1) {

f1.apply(true);return f1.apply(false);

}}.apply(new Fun<B,List>() {

public List apply(final B x1) {return

new Fun<Fun<B,List>,List>() {public List apply(Fun<B,List> f2) {

f2.apply(true);return f2.apply(false);


public List apply(final B x2) {return

...new Fun<Fun<B,List>,List>() {public List apply(Fun<B,List> fn) {

fn.apply(true);return fn.apply(false);


public List apply(final B xn) {return

new List{x1,x2,...xn};}}

Figure 6.1: Translation of kCFA EXPTIME-construction into an object-orientedlanguage.

100


{x1,x2,..xn}, where xi occur free with the context of the innermost “lambda”term, new Fun() {...}. To be truly faithful to the original construction, listswould be Church-encoded, and thus represented with a function of one argument,which is applied to x1 through xn. An analysis with a similar context abstractionto 1CFA will approximate the term representing the list x1,x2,...,xn withan abstract object that includes 1 bit of context information for each instancevariable, and thus there would be 2n values flowing from this program point, onefor each mapping xi to the calling context in which it was bound to either trueor false for all possible combinations. Grove and Chambers (2001) develop aframework for call-graph construction which can be instantiated in the style of1CFA and the construction above should be adaptable to show this instantiation isEXPTIME-hard.

A related question is whether the insights about linearity can be carried over tothe setting of pointer analysis in a first-order language to obtain simple proofs oflower bounds. If so, is it possible higher-order constructions can be transformedsystematically to obtain first-order constructions?

Type hierarchy analysis is a kind of class analysis particularly relevant to the dis-cussion in section 2.5 and the broader applicability of the approach to provinglower bounds employed in chapter 3. Type hierarchy analysis is an analysis of stat-ically typed object-oriented languages that bounds the set of procedures a methodinvocation may call by examining the type hierarchy declarations for method over-rides. “Type hierarchy analysis does not examine what the program actually does,just its type and method declarations,” (Diwan et al. 1996). It seems unlikelythat the technique of section 2.5 can be applied to prove lower bounds about thisanalysis since it has nothing to do with approximating evaluation.

6.7 Pointer Analysis

Just as flow analysis plays a fundamental role in the analysis of higher-order func-tional programs, pointer analysis6 plays a fundamental role in imperative lan-guages with pointers (Landi 1992a) and object-oriented languages, and informslater program analyses such as live variables, available expressions, and constantpropagation. Moreover, flow and alias analysis variants are often developed along

6Also known as alias and points-to analysis.

101


the same axes and have natural analogues with each other.

For example, Henglein’s (1992) simple closure analysis and Steensgaard’s (1996)points-to analysis are natural analogues. Both operate in near linear time by rely-ing on equality-based (rather than inclusion-based) set constraints, which can beimplemented using a union-find data-structure. Steensgaard algorithm “is inspiredby Henglein’s (1991) binding time analysis by type inference,” which also formsthe conceptual basis for Henglein (1992). Palsberg’s (1995) and Heintze’s (1994)constraint-based flow analysis and Andersen’s (1994) pointer analysis are simi-larly analogous and bear a strong resemblance in their use of subset constraints.

To get a full sense of the correspondence between pointer analysis and flow anal-ysis, read their respective surveys in parallel (Hind 2001; Midtgaard 2007). Thesecomprise major, mostly independent, lines of research. Given the numerous analo-gies, it is natural to wonder what the pointer analysis parallels are to the resultspresented in this dissertation. The landscape of the pointer analysis literature ismuch like that of flow analysis; there are hundreds of papers; similar, over-loaded,and abused terminology is frequently used; it concerns a huge variety of tools,frameworks, notations, proof techniques, implementation techniques, etc. With-out delving into too much detail, we recall some of the fundamental concepts ofpointer analysis, cite relevant results, and try to more fully develop the analogiesbetween flow analysis and pointer analysis.

A pointer analysis attempts to statically determine the possible run-time valuesof a pointer. Given a program and two variables p and q, points-to analysis de-termines if p can point to q (Chakaravarthy 2003). It is clear that in general,like all interesting properties of programs, it is not decidable if p can point q.A traditional assumption in this community is that all paths in the program areexecutable. However, even under this conservative assumption, the problem isundecidable. The history of pointer analysis can be understood largely in terms ofthe trade-offs between complexity and precision.

Analyses are characterized along several dimensions (Hind 2001), but of particu-lar relevance are those of:

• Equality-based: assignment is treated as an undirected flow of values.

• Subset-based: assignment is treated as a directed flow of values.

• Flow sensitivity

102


A points-to analysis is flow-sensitive analysis if it is given the control flowgraph for the analyzed program. The control flow graphs informs the pathsconsidered when determining the points-to relation. A flow-insensitive anal-ysis is not given the control flow graph and it is assumed statements can beexecuted in any order. See also section 4.4 of Hind (2001) and section 2.3of Rinetzky et al. (2008).

• Context sensitivity

calling context is considered when analyzing a function so that calls returnto their caller. See also section 4.4 of (Hind 2001).

Bravenboer and Smaragdakis (2009) remark:

In full context-sensitive pointer analysis, there is an ongoing searchfor context abstractions that provide precise pointer information,and do not cause massive redundant computation.7

The complexity of pointer analysis has been deeply studied (Myers 1981; Landiand Ryder 1991; Landi 1992a,b; Choi et al. 1993; Ramalingam 1994; Horwitz1997; Muth and Debray 2000; Chatterjee et al. 2001; Chakaravarthy and Horwitz2002; Chakaravarthy 2003; Rinetzky et al. 2008).

Flow sensitive points-to analysis with dynamic memory is not decidable (Landi1992b; Ramalingam 1994; Chakaravarthy 2003). Flow sensitive points-to anal-ysis without dynamic memory is PSPACE-hard (Landi 1992a; Muth and Debray2000), even when pointers are well-typed and restricted to only two levels ofdereferencing (Chakaravarthy 2003). Context-sensitive pointer analysis can bedone efficiently in practice (Emami et al. 1994; Wilson and Lam 1995). Flow andcontext-sensitive points-to analysis for Java can be efficient and practical even forlarge programs (Milanova et al. 2005).

See Muth and Debray (2000); Chakaravarthy (2003) for succinct overview ofcomplexity results and open problems.

7That search has been reflected in the functional community as well, see for example, Shivers(1991); Jagannathan and Weeks (1995); Banerjee (1997); Faxen (1997); Nielson and Nielson(1997); Sereni (2007); Ashley and Dybvig (1998); Wright and Jagannathan (1998); Might andShivers (2006a); Might (2007).

103


6.8 Logic Programming

McAllester (2002) argues “bottom-up logic program presentations are clearer andsimpler to analyze, for both correctness and complexity” and provides theoremsfor characterizing their run-time. McAllester argues bottom-up logic program-ming is especially appropriate for static analysis algorithms. The paper gives abottom-up logic presentation of evaluation (Fig. 4) and flow analysis (Fig 5.) forthe λ-calculus with pairing and uses the run-time theorem to derive a cubic upperbound for the analysis.

Recent work by Bravenboer and Smaragdakis (2009) demonstrates how Datalogcan be used to specify and efficiently implement pointer analysis. By the PTIME-completeness of Datalog, any analysis that can be specified is included in PTIME.

This bears a connection to the implicit computational complexity program, whichhas sought to develop syntactic means of developing programming languages thatcapture some complexity class (Hofmann 1998; Leivant 1993; Hofmann 2003;Kristiansen and Niggl 2004). Although this community has focused on generalpurpose programming languages—with only limited success in producing usablesystems—it seems that restricting the domain of interest to program analyzersmay be a fruitful line of work to investigate.

The EXPTIME construction of section 5.5 has a conceptual basis in Datalog com-plexity research (Hillebrand et al. 1995; Gaifman et al. 1993). See section 6.5 fora discussion.

6.9 Termination Analysis

Termination analysis of higher-order programs (Jones and Bohr 2008; Sereni andJones 2005; Giesl et al. 2006; Sereni 2007) is inherently tied to some underlyingflow analysis.

Recent work by Sereni and Jones on the termination analysis of higher-order lan-guages has relied on an initial control flow analysis of a program, the result ofwhich becomes input to the termination analyzer (Sereni and Jones 2005; Sereni2007). Once a call-graph is constructed, the so-called “size-change” principle8

8The size-change principle has enjoyed a complexity investigation in its own right (Lee et al. 2001;

104


can be used to show that there is no infinite path of decreasing size throughthrough the program’s control graph, and therefore the program eventually pro-duces an answer. This work has noted the inadequacies of 0CFA for producingprecise enough graphs for proving most interesting programs terminating. Mo-tivated by more powerful termination analyses, these researchers have designedmore powerful (i.e., more precise) control flow analyses, dubbed k-limited CFA.These analyses are parametrized by a fixed bound on the depth of environments,like Shivers’ kCFA. So for example, in 1-limited CFA, each variable is mapped tothe program point in which it is bound, but no information is retained about thisvalue’s environment. But unlike kCFA, this “limited” analysis is not polyvariant(context-sensitive) with respect to the most recent k calling contexts.

A lesson of our investigation into the complexity of kCFA is that it is not the poly-variance that makes the analysis difficult to compute, but rather the environments.Sereni notes that the k-limited CFA hierarchy “present[s] different characteristics,in particular in the aspects of precision and complexity” (Sereni 2007), howeverno complexity characterization is given.

6.10 Type Inference and Quantifier Elimination

Earlier work on the complexity of compile-time type inference is a precursor of theresearch insights described here, and naturally so, since type inference is a kindof static analysis (Mairson 1990; Henglein 1990; Henglein and Mairson 1991;Mairson 2004). The decidability of type inference depends on the making ofapproximations, necessarily rejecting programs without type errors; in simply-typed λ-calculus, for instance, all occurrences of a variable must have the sametype. (The same is, in effect, also true for ML, modulo the finite developmentimplicit in let-bindings.) The type constraints on these multiple occurrences aresolved by first-order unification.

As a consequence, we can understand the inherent complexity of type inference byanalyzing the expressive power of linear terms, where no such constraints exist,since linear terms are always simply-typable. In these cases, type inference issynonymous with normalization.9 This observation motivates the analysis of type

Ben-Amram and Lee 2007).9An aberrant case of this phenomenon is examined by Møller Neergaard and Mairson (2004),which analyzed a type system where normalization and type inference are synonymous in every

105


inference described by Mairson (1990, 2004).

Compared to flow analysis, type reconstruction has enjoyed a much more thor-ough complexity analysis.

A key observation about the type inference problem for simply typed λ-terms isthat, when the term is linear (every bound variable occurs exactly once), the mostgeneral type and normal form are isomorphic (Hindley 1989; Hirokawa 1991;Henglein and Mairson 1991; Mairson 2004). So given a linear term in normalform, we can construct its most general type (no surprise there), but conversely,when given a most general type, we can construct the normal form of all termswith that type.

This insight becomes the key ingredient in proving the lower bound complexity ofsimple-type inference—when the program is linear, static analysis is effectively“running” the program. Lower bounds, then, can be obtained by simply hackingwithin the linear λ-calculus.

Aside: The normal form of a linear program can be “read back”from its most general type in the following way: given a type σ1 →σ2 → . . . → σk → α, where α is a type variable, we can con-clude the normal form has the shape λx1.λx2. . . . λxk.e. Since theterm is linear, and the type is most general, every type variable oc-curs exactly twice: once positively and once negatively. Furthermore,there exists a unique σi ≡ τ1 → τ2 → . . . → τm → α, so ximust be the head variable of the normal form, i.e., we now know:λx1.λx2. . . . λxk.x1e

′, and xi is applied to m arguments, each withtype τ1, . . . , τm, respectively. But now, by induction, we can recur-sively construct the normal forms of the arguments. The base caseoccurs when we get to a base type (a type variable); here the termis just the occurrence of the λ-bound variable that has this (unique)type. In other words, a negative type-variable occurrence marks aλ-binding, while the corresponding positive type-variable occurrencemarks the single occurrence of the bound variable. The rest of theterm structure is determined in a syntax-directed way by the arrowstructure of the type.

It has been known for a long time that type reconstruction for the simply typed

case. The tractability of type inference thus implied a certain inexpressiveness of the language.

106


λ-calculus is decidable (Curry 1969; Hindley 1969), i.e. it is decidable whether aterm of the untyped λ-calculus is the image under type-erasing of a term of thesimply typed λ-calculus.10 Wand (1987) gave the first direct reduction to the uni-fication problem (Herbrand 1930; Robinson 1965; Dwork et al. 1984; Kanellakiset al. 1991). Henglein (1991, 1992) used unification to develop efficient type infer-ence for binding time analysis and flow analysis, respectively. This work directlyinspired the widely influential Steensgaard (1996) algorithm.11

A lower bound on the complexity of type inference can often be leveraged by thecombinatorial power behind a quantifier elimination procedure (Mairson 1992a).These procedures are syntactic transformations that map programs into potentiallylarger programs that can been typed in a simpler, quantifier-free setting.

As an example, consider the case of ML polymorphism. The universal quantifi-cation introduced by let-bound values can be eliminated by reducing all let-redexes. The residual program is simply-typable if, and only if, the original pro-gram is ML-typable.

This is embodied in the following inference rule:12

Γ `M : τ0 Γ ` [M/x]N : τ1

Γ ` let x = M in N : τ1

The residual may be exponentially larger due to nested let expressions that mustall be eliminated. From a Curry-Howard perspective, this can be seen as a form ofcut-elimination. From a computational perspective, this can be seen as a boundedrunning of the program at compile time. From a software engineering perspective,this can be seen as code-reuse—the ML-type inference problem has been reducedto the simple-type inference problem, and thus to first-order unification. But theprice is that an exponential amount of work may now be required.

Full polymorphism is undecidable, but ML offers a limit form of outermost uni-versal quantification. But this restriction relegates polymorphic functions to asecond-class citizenship, so in particular, functions passed as arguments to func-tions (a staple of higher-order programming) can only be used monomorphically.10See Tiuryn (1990) for a survey of type inference problems, cited in Cardone and Hindley (2006).11See section 6.7 for more on the relation of pointer analysis and flow analysis.12In the survey, Type systems for programming languages, Mitchell (1990) attributes this observa-

tion to Albert Meyer. Henglein and Mairson (1991, page 122) point out in a footnote that it alsoappears in the thesis of Damas (1985), and is the subject of a question on the 1985 postgraduateexamination in computing at Edinburgh University.

107


Intersection types restore first-class polymorphism by offering a finite form ofexplicit quantification over simple types. The type τ1 ∧ τ2 is used for a term thatis typable as both τ1 and τ2. This can formalized as the following inference rulefor ∧:13

Γ1 `M : τ1 Γ2 `M : τ2

Γ1 ∧ Γ2 `M : τ1 ∧ τ2

where ∧ is lifted to environments in a straightforward way. Notice that this allowsexpressions such as,

(λf.λz.z(f 2)(f false)) (λx.x),

to be typed where x has type int ∧ bool.

The inference rule, as stated, breaks syntax-directed inference. van Bakel (1992)observed that by limiting the rule to the arguments of function application, syntax-direction can be recovered without changing the set of typable terms (althoughsome terms will have fewer typings). Such systems are called strict intersectionssince the ∧ can occur only on the left of a function type.

The finite ∧-quantifiers of strict intersections too have an elimination procedure,which can be understood as a program transformation that eliminates ∧-quant-ification by rank. A type is rank r if there are no occurrences of ∧ to the left ofr occurrences of an arrow. The highest rank intersections can be eliminated byperforming a minimal complete development.

Every strongly normalizing term has an intersection type, so type inference ingeneral is undecidable. However, decidable fragments can be regained by a stan-dard approach of applying a rank restriction, limiting the depth of ∧ to the left ofa function type.

By bounding the rank, inference becomes decidable; if the rank is bound at k,k developments suffice to eliminate all intersections. The residual program issimply-typable if, and only if, the original program is rank-k intersection typable.Since each development can cause the program to grow by an exponential factor,iteratively performing k-MCD’s results in an elementary lower bound (Kfouryet al. 1999; Møller Neergaard and Mairson 2004).

The special case of rank-2 intersection types have proved to be an importantcase with applications to modular flow analysis, dead-code elimination, and typ-13This presentation closely follows the informal presentation of intersection types in Chapter 4 of

Møller Neergaard (2004).

108


ing polymorphic recursion, local definitions, conditionals and pattern matching(Damiani and Prost 1998; Damiani 2003; Banerjee and Jensen 2003; Damiani2007).

System F, the polymorphic typed λ-calculus (Reynolds 1974; Girard et al. 1989),has an undecidable Curry-style inference problem (Wells 1999). Partial inferencein a Church-style system is investigated by Boehm (1985); Pfenning (1993) andPfenning’s result shows even partial inference for a simple predicative fragmentis undecidable.

The quantifier-elimination approach to proving lower bounds was extended toSystem Fω by Henglein and Mairson (1991). They prove a sequence of lowerbounds on recognizing the System Fk-typable terms, where the bound for Fk+1 isexponentially larger than that for Fk. This is analogous to intersection quantifierelimination via complete developments at the term level. The essence of Hengleinand Mairson (1991) is to compute developments at the kind level to shift from Sys-tem Fk+1 to System Fk typability. This technique led to lower bounds on SystemFi and the non-elementary bound on System Fω (Henglein and Mairson 1991).Urzyczyn (1997) showed Curry-style inference for System Fω is undecidable.

There are some interesting open complexity problems in the realm of type in-ference and quantifier elimination. Bounded polymorphic recursion has recentlybeen investigated (Comini et al. 2008), and is decidable but with unknown com-plexity bounds, nor quantifier elimination procedures. Typed Scheme (Tobin-Hochstadt and Felleisen 2008), uses explicit annotations, but with partial inferenceand flow sensitivity. It includes intersection rules for function types. Complexitybounds on type checking and partial inference are unknown.

The simple algorithm of Wand (1987), which generates constraints for type re-construction, can also be seen as compiler for the linear λ-calculus. It compiles alinear term into a “machine language” of first-order constraints of the form a = band c = d → e. This machine language is the computational analog of logic’sown low-level machine language for first-order propositional logic, the machine-oriented logic of Robinson (1965).

Unifying these constraints effectively runs the machine language, evaluating theoriginal program, producing an answer in the guise of a solved form of the type,which is isomorphic to the normal form of the program.

Viewed from this perspective, this is an instance of normalization-by-evaluationfor the linear λ-calculus. A linear term is mapped into the domain of first-order

109


logic, where unification is used to evaluate to a canonical solved form, whichcan be mapped to the normal form of the term. Constraint-based formulations ofmonovariant flow analyses analogously can be seen as instances of weak normal-ization-by-evaluation functions for the linear λ-calculus.

110

Chapter 7

Conclusions and Perspective

7.1 Contributions

Flow analysis is a fundamental static analysis of functional, object-oriented, andother higher-order programming languages; it is a ubiquitous and much-studiedcomponent of compiler technology with nearly thirty years of research on thetopic. This dissertation has investigated the computational complexity of flowanalysis in higher-order programming languages, yielding novel insights into thefundamental limitations on the cost of performing flow analysis.

Monovariant flow analysis, such as 0CFA, is complete for polynomial time. More-over, many further approximations to 0CFA from the literature, such as Henglein’ssimple closure analysis, remain complete for polynomial time. These theoremsrely on the fact that when a program is linear (each bound variable occurs exactlyonce), the analysis makes no approximation; abstract and concrete interpretationcoincide. More generally, we conjecture any abstract and concrete interpretationwill have some sublanguage of coincidence, and this sublanguage may be usefulin proving lower bounds.

The linear λ-calculus has been identified as an important language subset to studyin order to understand flow analysis. Linearity is an equalizer among variants ofstatic analysis, and a powerful tool in proving lower bounds. Analysis of linearprograms coincide under both equality and inclusion-based flow constraints, andmoreover, concrete and abstract interpretation coincide for this core language. The

111

CHAPTER 7. CONCLUSIONS AND PERSPECTIVE

inherently sequential nature of flow analysis can be understood as a consequenceof a lack of abstraction on this language subset.

Since linearity plays such a fruitful role in the study of program analysis, wedeveloped connections with linear logic and the technology of sharing graphs.Monovariant analysis can be formulated graphically, and the technology of graphreduction and optimal evaluation can be applied to flow analysis. The explicitcontrol representation of sharing graphs makes it easy to extend flow analysis tolanguages with first-class control.

Simply-typed, η-expanded programs have a potentially simpler 0CFA problem,which is complete for logarithmic space. This discovery is based on analogieswith proof normalization for multiplicative linear logic with atomic axioms.

Shivers’ polyvariant kCFA, for any k > 0, is complete for deterministic expo-nential time. This theorem validates empirical observations that such control flowanalysis is intractable. A fairly straightforward calculation shows that kCFA canbe computed in exponential time. We show that the naive algorithm is essentiallythe best one. There is, in the worst case—and plausibly, in practice—no way totame the cost of the analysis. Exponential time is required.

Collectively, these results provide general insight into the complexity of abstractinterpretation and program analysis.

7.2 Future Work

We end by outlining some new directions and open problems worth pursuing, inapproximately ascending order of ambition and import.

7.2.1 Completing the Pointer Analysis Complexity Story

Compared with flow analysis, pointer analysis has received a much more thor-ough complexity investigation. A series of important refinements have been madeby Landi and Ryder (1991); Landi (1992a,b); Choi et al. (1993); Horwitz (1997);Muth and Debray (2000); Chatterjee et al. (2001); Chakaravarthy (2003), yet openproblems persist. Chakaravarthy (2003) leaves open the lower bound on the com-plexity of pointer analysis with well-defined types with less than two levels of

112


dereference. We believe our insights into linearity and circuit construction canlead to an answer to this remaining problem.

7.2.2 Polyvariant, Polynomial Flow Analyses

To echo the remark of Bravenboer and Smaragdakis (2009), only adapted to thesetting of flow analysis rather than pointer analysis, there is an ongoing search forpolyvariant, or context-sensitive, analyses that provide precise flow informationwithout causing massive redundant computation. There has been important workin this area (Jagannathan and Weeks 1995; Nielson and Nielson 1997), but thelandscape of tractable, context-sensitive flow analyses is mostly open and in needof development.

The ingredients, detailed in chapter 5, that combine to make kCFA hard, whenk > 0, should provide guidance in designing new abstractions that avoid com-putationally expensive components of analysis. A lesson learned has been thatclosures, as they exist when k > 0, result in an exponential value space that canbe harnessed for the EXPTIME lower-bound construction. It should be possibleto design alternative closure abstractions while remaining both polyvariant andpolynomial (more below).

7.2.3 An Expressive Hierarchy of Flow Analyses

From the perspective of computational complexity, the kCFA hierarchy is flat (forany fixed k, kCFA is in EXPTIME; see section 5.2). On the other hand, there arefar more powerful analyses such as those of Burn et al. (1985) and Mossin (1998).How can we systematically bridge the gap between these analyses to obtain a realexpressivity hierarchy?

Flow analyses based on rank-bounded intersection types offers one approach. Itshould also be possible to design such analyses by composing notions of pre-cise but bounded computation—such as partial evaluation or a series of completedevelopments—followed by course analysis of residual programs. The idea isto stage analysis into two phases: the first eliminates the need for polyvariancein analysis by transforming the original program into an equivalent, potentiallylarger, residual program. The subsequent stage performs a course (monovariant)analysis of the residual program. By staging the analysis in this manner—first

113


computing a precise but bounded program evaluation, then an imprecise eval-uation approximation—the “ever-worsening feedback loop” (Might and Shivers2006b) is avoided. By using a sufficiently powerful notion of bounded evalua-tion, it should be possible to construct flow analyses that form a true hierarchyfrom a complexity perspective. By using a sufficiently weak notion of boundedevaluation, it should be possible to construct flow analyses that are arbitrarilypolyvariant, but computable in polynomial time.

7.2.4 Truly Subcubic Inclusion-Based Flow Analysis

This dissertation has focused on lower bounds, however recent upper bound im-provements have been made on the “cubic bottleneck” of inclusion-based flowanalyses such as 0CFA (Midtgaard and Van Horn 2009). These results have shownknown set compression techniques can be applied to obtain direct 0CFA algo-rithms that run in O(n3/ log n) time on a unit cost random-access memory modelmachine. While these results do provide a logarithmic improvement, it is natu-ral to wonder if there is a O(nc) algorithm for 0CFA and related analyses, wherec < 3.

At the same time, there have been recent algorithmic breakthroughs on the all-pairs shortest path problem resulting in truly subcubic algorithms. Perhaps thegraphical formulation of flow analysis from chapter 4 can be adapted to exploitthese breakthroughs.

7.2.5 Toward a Fundamental Theorem of Static Analysis

A theorem due to Statman (1979) says this: let P be a property of simply-typedλ-terms that we would like to detect by static analysis, where P is invariant un-der reduction (normalization), and is computable in elementary time (polynomial,or exponential, or doubly-exponential, or. . . ). Then P is a trivial property: forany type τ , P is satisfied by all or none of the programs of type τ . Hengleinand Mairson (1991) have complemented these results, showing that if a propertyis invariant under β-reduction for a class of programs that can encode all TuringMachines solving problems of complexity class F using reductions from complex-ity class G, then any superset is either F-complete or trivial. Simple typability hasthis property for linear and linear affine λ-terms (Henglein and Mairson 1991;

114


Mairson 2004), and these terms are sufficient to code all polynomial-time TuringMachines.

We would like to prove some analogs of these theorems, with or without the typingcondition, but weakening the condition of “invariant under reduction” to “invariantunder abstract interpretation.”

115

Bibliography

Harold Abelson and Gerald J. Sussman. Structure and Interpretation of Com-puter Programs. MIT Press, Cambridge, Massachusetts, USA, 1996. ISBN0262011530. Cited on pages xvi, 11, and 28.

Alfred V. Aho, John E. Hopcroft, and Jeffrey D. Ullmana. Time and tape complex-ity of pushdown automaton languages. Information and Control, 13(3):186–206, 1968. Cited on pages 49 and 95.

Marıa Alpuente and German Vidal, editors. Static Analysis, 15th InternationalSymposium, SAS 2008, Valencia, Spain, July 16-18, 2008. Proceedings, volume5079 of Lecture Notes in Computer Science. Springer, 2008. ISBN 978-3-540-69163-1. Cited on pages 120, 130, and 138.

Torben Amtoft and Franklyn A. Turbak. Faithful translations between polyvariantflows and polymorphic types. In ESOP ’00: Proceedings of the 9th EuropeanSymposium on Programming Languages and Systems, pages 26–40. Springer-Verlag, London, UK, 2000. ISBN 3-540-67262-1. Cited on page 72.

Lars Ole Andersen. Program Analysis and Specialization for the C ProgrammingLanguage. Ph.D. thesis, DIKU, University of Copenhagen, 1994. Cited onpage 102.

J. Michael Ashley and R. Kent Dybvig. A practical and flexible flow analysisfor higher-order languages. ACM Trans. Program. Lang. Syst., 20(4):845–868,1998. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/291891.291898. Citedon pages 7, 31, 50, and 103.

Andrea Asperti and Cosimo Laneve. Paths, computations and labels in the λ-calculus. Theor. Comput. Sci., 142(2):277–297, 1995. ISSN 0304-3975. doi:http://dx.doi.org/10.1016/0304-3975(94)00279-7. Cited on page 72.

117

http://doi.acm.org/10.1145/291891.291898

http://dx.doi.org/10.1016/0304-3975(94)00279-7

BIBLIOGRAPHY

Andrea Asperti and Harry G. Mairson. Parallel beta reduction is not elementaryrecursive. In POPL 1998, pages 303–315. doi: http://doi.acm.org/10.1145/268946.268971. Cited on page 67.

Andrew Edward Ayers. Abstract analysis and optimization of Scheme. Ph.D.thesis, Cambridge, Massachusetts, USA, 1993. Cited on page 57.

David F. Bacon and Peter F. Sweeney. Fast static analysis of C++ virtual functioncalls. In OOPSLA 1996, pages 324–341. doi: http://doi.acm.org/10.1145/236337.236371. Cited on pages 97, 98, and 99.

Anindya Banerjee. A modular, polyvariant and type-based closure analysis. InBerman (1997), pages 1–10. doi: http://doi.acm.org/10.1145/258948.258951.Cited on pages 25 and 103.

Anindya Banerjee and Thomas Jensen. Modular control-flow analysis with rank2 intersection types. Mathematical. Structures in Comp. Sci., 13(1):87–124,2003. ISSN 0960-1295. doi: http://dx.doi.org/10.1017/S0960129502003845.Cited on pages 72 and 109.

Henk P. Barendregt. The Lambda Calculus: Its Syntax and Semantics, volume103 of Studies in Logic and the Foundations of Mathematics. North-Holland,revised edition, 1984. ISBN 0-444-87508-5. Cited on page xvi.

Henk P. Barendregt. Functional programming and lambda calculus. In vanLeeuwen (1990), pages 321–363. Cited on page xvi.

Julien Basch, Sanjeev Khanna, and Rajeev Motwani. On diameter verification andBoolean matrix multiplication. Technical report, Stanford University, Stanford,California, USA, 1995. Cited on page 95.

Amir M. Ben-Amram and Chin Soon Lee. Program termination analysis in poly-nomial time. ACM Trans. Program. Lang. Syst., 29(1):5, 2007. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/1180475.1180480. Cited on page 105.

A. Michael Berman, editor. ICFP ’97: Proceedings of the second ACM SIGPLANInternational Conference on Functional Programming. ACM, New York, NewYork, USA, 1997. ISBN 0-89791-918-1. Cited on pages 118 and 124.

Sandip K. Biswas. A demand-driven set-based analysis. In POPL 1997, pages372–385. doi: http://doi.acm.org/10.1145/263699.263753. Cited on page 57.

118

http://doi.acm.org/10.1145/268946.268971

http://doi.acm.org/10.1145/268946.268971

http://doi.acm.org/10.1145/236337.236371

http://doi.acm.org/10.1145/236337.236371

http://doi.acm.org/10.1145/258948.258951

http://dx.doi.org/10.1017/S0960129502003845

http://doi.acm.org/10.1145/1180475.1180480

http://doi.acm.org/10.1145/263699.263753

BIBLIOGRAPHY

Hans-J. Boehm. Partial polymorphic type inference is undecidable. In SFCS’85: Proceedings of the 26th Annual Symposium on Foundations of ComputerScience (SFCS 1985), pages 339–345. IEEE Computer Society, Washington,DC, USA, 1985. ISBN 0-8186-0844-4. doi: http://dx.doi.org/10.1109/SFCS.1985.44. Cited on page 109.

Martin Bravenboer and Yannis Smaragdakis. Strictly declarative specification ofsophisticated points-to analyses. In OOPSLA ’09: Proceedings of the 24th an-nual ACM SIGPLAN Conference on Object-Oriented Programming, Systems,Languages, and Applications. 2009. To appear. Cited on pages 103, 104,and 113.

G. L. Burn, C. L. Hankin, and S. Abramsky. The theory of strictness analysis forhigher order functions. In H. Ganzinger and N. Jones, editors, Programs asdata objects, pages 42–62. Springer-Verlag, New York, New York, USA, 1985.ISBN 0-387-16446-4. Cited on pages 87 and 113.

Felice Cardone and J. Roger Hindley. History of lambda-calculus and combina-tory logic. Technical Report MRRS-05-06, Swansea University MathematicsDepartment Research Report, 2006. To appear in Handbook of the History ofLogic, Volume 5, D. M. Gabbay and J. Woods, editors. Cited on pages xviand 107.

Venkatesan T. Chakaravarthy. New results on the computability and complexityof points–to analysis. In POPL ’03: Proceedings of the 30th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 115–125. ACM, New York, New York, USA, 2003. ISBN 1-58113-628-5. doi:http://doi.acm.org/10.1145/604131.604142. Cited on pages 102, 103, and 112.

Venkatesan T. Chakaravarthy and Susan Horwitz. On the non-approximability ofpoints-to analysis. Acta Informatica, 38(8):587–598, 2002. doi: http://dx.doi.org/10.1007/s00236-002-0081-8. Cited on page 103.

Craig Chambers and David Ungar. Interactive type analysis and extended messagesplitting; optimizing dynamically-typed object-oriented programs. In PLDI’90: Proceedings of the ACM SIGPLAN 1990 Conference on ProgrammingLanguage Design and Implementation, pages 150–164. ACM, New York, NewYork, USA, 1990. ISBN 0-89791-364-7. doi: http://doi.acm.org/10.1145/93542.93562. Cited on page 97.

119

http://dx.doi.org/10.1109/SFCS.1985.44


http://doi.acm.org/10.1145/604131.604142

http://dx.doi.org/10.1007/s00236-002-0081-8

http://dx.doi.org/10.1007/s00236-002-0081-8

http://doi.acm.org/10.1145/93542.93562

http://doi.acm.org/10.1145/93542.93562

BIBLIOGRAPHY

Timothy M. Chan. More algorithms for all-pairs shortest paths in weightedgraphs. In STOC ’07: Proceedings of the thirty-ninth annual ACM Symposiumon Theory of Computing, pages 590–598. ACM, New York, New York, USA,2007. ISBN 978-1-59593-631-8. doi: http://doi.acm.org/10.1145/1250790.1250877. Cited on page 95.

Ramkrishna Chatterjee, Barbara G. Ryder, and William A. Landi. Complexityof points-to analysis of Java in the presence of exceptions. IEEE Trans. Softw.Eng., 27(6):481–512, 2001. ISSN 0098-5589. doi: http://dx.doi.org/10.1109/32.926173. Cited on pages 103 and 112.

Swarat Chaudhuri. Subcubic algorithms for recursive state machines. In POPL2008, pages 159–169. doi: http://doi.acm.org/10.1145/1328438.1328460.Cited on pages 50 and 95.

Jong-Deok Choi, Michael Burke, and Paul Carini. Efficient flow-sensitive inter-procedural computation of pointer-induced aliases and side effects. In POPL1993, pages 232–245. doi: http://doi.acm.org/10.1145/158511.158639. Citedon pages 103 and 112.

Marco Comini, Ferruccio Damiani, and Samuel Vrech. On polymorphic recur-sion, type systems, and abstract interpretation. In Alpuente and Vidal (2008),pages 144–158. doi: http://dx.doi.org/10.1007/978-3-540-69166-2 10. Citedon page 109.

Patrick Cousot and Radhia Cousot. Abstract interpretation: a unified lattice modelfor static analysis of programs by construction or approximation of fixpoints.In POPL ’77: Proceedings of the 4th ACM SIGACT-SIGPLAN Symposium onPrinciples of Programming Languages, pages 238–252. ACM, New York, NewYork, USA, 1977. doi: http://doi.acm.org/10.1145/512950.512973. Cited onpages 3 and 18.

Patrick Cousot and Radhia Cousot. Abstract interpretation frameworks. Journalof Logic and Computation, 2(4):511–547, 1992. Cited on page 3.

Haskell B. Curry. Modified basic functionality in combinatory logic. Dialectica,23(2):83–92, 1969. doi: http://dx.doi.org/10.1111/j.1746-8361.1969.tb01183.x. Cited on page 107.

120

http://doi.acm.org/10.1145/1250790.1250877

http://doi.acm.org/10.1145/1250790.1250877

http://dx.doi.org/10.1109/32.926173

http://dx.doi.org/10.1109/32.926173

http://doi.acm.org/10.1145/1328438.1328460

http://doi.acm.org/10.1145/158511.158639

http://dx.doi.org/10.1007/978-3-540-69166-2_10

http://doi.acm.org/10.1145/512950.512973

http://dx.doi.org/10.1111/j.1746-8361.1969.tb01183.x

http://dx.doi.org/10.1111/j.1746-8361.1969.tb01183.x

BIBLIOGRAPHY

Luis Damas. Type assignment in programming languages. Ph.D. thesis, Univer-sity of Edinburgh, Department of Computer Science, 1985. Technical ReportCST- 33-85. Cited on page 107.

Daniel Damian and Olivier Danvy. CPS transformation of flow information, PartII: administrative reductions. J. Funct. Program., 13(5):925–933, 2003. ISSN0956-7968. doi: http://dx.doi.org/10.1017/S0956796803004702. Cited on page92.

Ferruccio Damiani. Rank 2 intersection types for local definitions and conditionalexpressions. ACM Trans. Program. Lang. Syst., 25(4):401–451, 2003. ISSN0164-0925. doi: http://doi.acm.org/10.1145/778559.778560. Cited on page109.

Ferruccio Damiani. Rank 2 intersection for recursive definitions. Fundam. Inf.,77(4):451–488, 2007. ISSN 0169-2968. Cited on page 109.

Ferruccio Damiani and Frederic Prost. Detecting and removing dead-code usingrank 2 intersection. In TYPES ’96: Selected papers from the InternationalWorkshop on Types for Proofs and Programs, pages 66–87. Springer-Verlag,London, UK, 1998. ISBN 3-540-65137-3. Cited on page 109.

Olivier Danvy and Andrzej Filinski. Abstracting control. In LFP ’90: Proceedingsof the 1990 ACM conference on LISP and Functional Programming, pages 151–160. ACM Press, New York, New York, USA, 1990. ISBN 0-89791-368-X. doi:http://doi.acm.org/10.1145/91556.91622. Cited on page 70.

Olivier Danvy, Karoline Malmkjær, and Jens Palsberg. Eta-expansion does thetrick. ACM Trans. Program. Lang. Syst., 18(6):730–751, 1996. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/236114.236119. Cited on page 69.

Greg DeFouw, David Grove, and Craig Chambers. Fast interprocedural class anal-ysis. In POPL 1998, pages 222–236. doi: http://doi.acm.org/10.1145/268946.268965. Cited on page 98.

Roberto Di Cosmo, Delia Kesner, and Emmanuel Polonovski. Proof nets andexplicit substitutions. Mathematical. Structures in Comp. Sci., 13(3):409–450,2003. ISSN 0960-1295. doi: http://dx.doi.org/10.1017/S0960129502003791.Cited on page 61.

121

http://dx.doi.org/10.1017/S0956796803004702

http://doi.acm.org/10.1145/778559.778560

http://doi.acm.org/10.1145/91556.91622

http://doi.acm.org/10.1145/236114.236119

http://doi.acm.org/10.1145/268946.268965

http://doi.acm.org/10.1145/268946.268965

http://dx.doi.org/10.1017/S0960129502003791

BIBLIOGRAPHY

Amer Diwan, J. Eliot B. Moss, and Kathryn S. McKinley. Simple and effectiveanalysis of statically-typed object-oriented programs. In OOPSLA 1996, pages292–305. doi: http://doi.acm.org/10.1145/236337.236367. Cited on pages 98and 101.

Cynthia Dwork, Paris C. Kanellakis, and John C. Mitchell. On the sequentialnature of unification. J. Log. Program., 1(1):35–50, 1984. ISSN 0743-1066.doi: http://dx.doi.org/10.1016/0743-1066(84)90022-0. Cited on page 107.

R. Kent Dybvig. The Scheme Programming Language. MIT Press, third edition,2002. Published online: http://www.scheme.com/tspl3/. Cited on page xvi.

Maryam Emami, Rakesh Ghiya, and Laurie J. Hendren. Context-sensitive in-terprocedural points-to analysis in the presence of function pointers. In PLDI’94: Proceedings of the ACM SIGPLAN 1994 Conference on ProgrammingLanguage Design and Implementation, pages 242–256. ACM, New York, NewYork, USA, 1994. ISBN 0-89791-662-X. doi: http://doi.acm.org/10.1145/178243.178264. Cited on page 103.

Jon Erickson. Hacking: The Art of Exploitation. No Starch Press, 2 edition, 2008.ISBN 1-59327-144-1. Cited on page 27.

Karl-Filip Faxen. Optimizing lazy functional programs using flow inference. InMycroft (1995), pages 136–153. Cited on page 25.

Karl-Filip Faxen. Polyvariance, polymorphism and flow analysis. In Selected pa-pers from the 5th LOMAPS Workshop on Analysis and Verification of Multiple-Agent Languages, pages 260–278. Springer-Verlag, London, UK, 1997. ISBN3-540-62503-8. Cited on pages 25 and 103.

Matthias Felleisen and Matthew Flatt. Programming languages and lambda cal-culi. 2009. Soon to be published manuscript, in development since 1989. Citedon page 13.

Andrzej Filinski. Declarative continuations: an investigation of duality in pro-gramming language semantics. In Category Theory and Computer Science,pages 224–249. Springer-Verlag, London, UK, 1989. ISBN 3-540-51662-X.Cited on page 70.

Daniel P. Friedman and Mitchell Wand. Essentials of Programming Languages.MIT Press, third edition, 2008. ISBN 0-262-06279-8. Cited on page xvi.

122

http://doi.acm.org/10.1145/236337.236367

http://dx.doi.org/10.1016/0743-1066(84)90022-0

http://www.scheme.com/tspl3/

http://doi.acm.org/10.1145/178243.178264

http://doi.acm.org/10.1145/178243.178264

BIBLIOGRAPHY

Daniel P. Friedman, Mitchell Wand, and Christopher T. Haynes. Essentials ofProgramming Languages. MIT Press, first edition, 1992. ISBN 0-262-06145-7. Cited on page xvi.

Haim Gaifman, Harry Mairson, Yehoshua Sagiv, and Moshe Y. Vardi. Undecid-able optimization problems for database logic programs. J. ACM, 40(3):683–713, 1993. ISSN 0004-5411. doi: http://doi.acm.org/10.1145/174130.174142.Cited on pages 96 and 104.

Michael R. Garey and David S. Johnson. Computers and Intractability: A Guideto the Theory of NP-Completeness. W. H. Freeman & Co., New York, NewYork, USA, 1979. ISBN 0716710447. Cited on page 26.

Jurgen Giesl, Stephan Swiderski, Peter Schneider-Kamp, and Rene Thiemann.Automated termination analysis for Haskell: From term rewriting to program-ming languages. In Frank Pfenning, editor, RTA, volume 4098 of Lecture Notesin Computer Science, pages 297–312. Springer, 2006. ISBN 3-540-36834-5.Cited on page 104.

Jean-Yves Girard. Linear logic. Theor. Comput. Sci., 50(1):1–102, 1987. ISSN0304-3975. doi: http://dx.doi.org/10.1016/0304-3975(87)90045-4. Cited onpage 60.

Jean-Yves Girard. Geometry of interaction I: Interpretation of System F. InC. Bonotto, editor, Logic Colloquium ’88, pages 221–260. North Holland,1989. Cited on pages 65 and 88.

Jean-Yves Girard, Paul Taylor, and Yves Lafont. Proofs and types. CambridgeUniversity Press, New York, New York, USA, 1989. ISBN 0-521-37181-3.Reprinted with corrections 1990. Cited on pages xvii, 61, and 109.

Georges Gonthier, Martın Abadi, and Jean-Jacques Levy. The geometry of opti-mal lambda reduction. In POPL ’92: Proceedings of the 19th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 15–26.ACM Press, New York, New York, USA, 1992. ISBN 0-89791-453-8. doi:http://doi.acm.org/10.1145/143165.143172. Cited on pages 65 and 88.

Timothy G. Griffin. A formulae-as-type notion of control. In POPL 1990, pages47–58. doi: http://doi.acm.org/10.1145/96709.96714. Cited on page 72.

123

http://doi.acm.org/10.1145/174130.174142

http://dx.doi.org/10.1016/0304-3975(87)90045-4

http://doi.acm.org/10.1145/143165.143172

http://doi.acm.org/10.1145/96709.96714

BIBLIOGRAPHY

David Grove and Craig Chambers. A framework for call graph construction algo-rithms. ACM Trans. Program. Lang. Syst., 23(6):685–746, 2001. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/506315.506316. Cited on pages 97, 99,and 101.

Chris Hankin. An Introduction to Lambda Calculi for Computer Scientists. King’sCollege, 2004. ISBN 0-9543006-5-3. Cited on page xvi.

Chris Hankin, Rajagopal Nagarajan, and Prahladavaradan Sampath. The essenceof computation: complexity, analysis, transformation, chapter Flow analysis:games and nets, pages 135–156. Springer-Verlag New York, Inc., New York,New York, USA, 2002. ISBN 3-540-00326-6. Cited on page 51.

Robert Harper. Programming in Standard ML. 2005. Published online only:http://www.cs.cmu.edu/∼rwh/smlbook/, Working draft of December 6, 2007.Cited on page xvi.

Matthew S. Hecht. Flow Analysis of Computer Programs. Elsevier Science Inc.,New York, New York, USA, 1977. ISBN 0444002162. Cited on page 91.

Nevin Heintze. Set-based analysis of ML programs. In LFP ’94: Proceedings ofthe 1994 ACM Conference on LISP and Functional Programming, pages 306–317. ACM Press, New York, New York, USA, 1994. ISBN 0-89791-643-3. doi:http://doi.acm.org/10.1145/182409.182495. Cited on pages 25, 93, 94, and 102.

Nevin Heintze. Control-flow analysis and type systems. In Mycroft (1995), pages189–206. Cited on page 25.

Nevin Heintze and David McAllester. Linear-time subtransitive control flowanalysis. In PLDI ’97: Proceedings of the ACM SIGPLAN 1997 Confer-ence on Programming Language Design and Implementation, pages 261–272.ACM Press, New York, New York, USA, 1997a. ISBN 0-89791-907-6. doi:http://doi.acm.org/10.1145/258915.258939. Cited on pages 31, 51, and 95.

Nevin Heintze and David McAllester. On the complexity of set-based analysis.In Berman (1997), pages 150–163. doi: http://doi.acm.org/10.1145/258948.258963. Cited on pages 57, 91, and 95.

Nevin Heintze and David McAllester. On the cubic bottleneck in subtyping andflow analysis. In LICS ’97: Proceedings of the 12th Annual IEEE Symposium

124

http://doi.acm.org/10.1145/506315.506316

http://www.cs.cmu.edu/~rwh/smlbook/

http://doi.acm.org/10.1145/182409.182495

http://doi.acm.org/10.1145/258915.258939

http://doi.acm.org/10.1145/258948.258963

http://doi.acm.org/10.1145/258948.258963

BIBLIOGRAPHY

on Logic in Computer Science, page 342. IEEE Computer Society, Washington,DC, USA, 1997c. ISBN 0-8186-7925-5. Cited on pages 49, 50, and 95.

Fritz Henglein. Type invariant simulation: A lower bound technique for typeinference. 1990. Unpublished manuscript. Cited on pages 93 and 105.

Fritz Henglein. Efficient type inference for higher-order binding-time analysis.In Proceedings of the 5th ACM Conference on Functional Programming Lan-guages and Computer Architecture, pages 448–472. Springer-Verlag, London,UK, 1991. ISBN 3-540-54396-1. Cited on pages 102 and 107.

Fritz Henglein. Simple closure analysis. Technical report, 1992. DIKU SemanticsReport D-193. Cited on pages 7, 31, 36, 73, 102, and 107.

Fritz Henglein and Harry G. Mairson. The complexity of type inference forhigher-order lambda calculi. In POPL 1991, pages 119–130. doi: http://doi.acm.org/10.1145/99583.99602. Cited on pages 92, 93, 105, 106, 107,109, and 114.

Jacques Herbrand. Investigations in proof theory: The properties of true proposi-tions, pages 525–581. Harvard University Press, 1930. Chapter 5 of Herbrand’sPh.D. dissertation, Recherches sur la theorie de la deemonstration. Cited onpage 107.

Gerd G. Hillebrand, Paris C. Kanellakis, Harry G. Mairson, and Moshe Y. Vardi.Undecidable boundedness problems for datalog programs. J. Logic Program.,25(2):163–190, 1995. Cited on pages 96 and 104.

Michael Hind. Pointer analysis: haven’t we solved this problem yet? In PASTE’01: Proceedings of the 2001 ACM SIGPLAN-SIGSOFT Workshop on ProgramAnalysis for Software Tools and Engineering, pages 54–61. ACM, New York,New York, USA, 2001. ISBN 1-58113-413-4. doi: http://doi.acm.org/10.1145/379605.379665. Cited on pages 102 and 103.

J. Roger Hindley. The principal type-scheme of an object in combinatory logic.Transactions of the American Mathematical Society, pages 29–60, 1969. Citedon page 107.

J. Roger Hindley. BCK-combinators and linear λ-terms have types. Theor. Com-put. Sci., 64:97–105, 1989. Cited on pages 92 and 106.

125

http://doi.acm.org/10.1145/99583.99602

http://doi.acm.org/10.1145/99583.99602

http://doi.acm.org/10.1145/379605.379665

http://doi.acm.org/10.1145/379605.379665

BIBLIOGRAPHY

Sachio Hirokawa. Principal type-schemes of BCI-lambda-terms. In TACS ’91:Proceedings of the International Conference on Theoretical Aspects of Com-puter Software, pages 633–650. Springer-Verlag, London, UK, 1991. ISBN3-540-54415-1. Cited on pages 92 and 106.

Martin Hofmann. Type Systems for Polynomial-Time Computation. Ph.D. thesis,TU Darmstadt, 1998. Habilitation Thesis. Cited on page 104.

Martin Hofmann. Linear types and non-size-increasing polynomial time com-putation. Inf. Comput., 183(1):57–85, 2003. ISSN 0890-5401. doi: http://dx.doi.org/10.1016/S0890-5401(03)00009-9. Cited on page 104.

Susan Horwitz. Precise flow-insensitive may-alias analysis is NP-hard. ACMTrans. Program. Lang. Syst., 19(1):1–6, 1997. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/239912.239913. Cited on pages 103 and 112.

William A. Howard. The formulae-as-types notion of construction. In Seldin andHindley (1980), pages 479–490. Cited on page 59.

ICFP’07. Proceedings of the 2007 ACM SIGPLAN International Conference onFunctional Programming, Freiburg, Germany, October 1–3. ACM, New York,New York, USA, 2007. ISBN 978-1-59593-815-2. Cited on pages 136 and 138.

Suresh Jagannathan, Peter Thiemann, Stephen Weeks, and Andrew Wright. Sin-gle and loving it: must-alias analysis for higher-order languages. In POPL1998, pages 329–341. doi: http://doi.acm.org/10.1145/268946.268973. Citedon pages 4 and 92.

Suresh Jagannathan and Stephen Weeks. A unified treatment of flow analy-sis in higher-order languages. In POPL ’95: Proceedings of the 22nd ACMSIGPLAN-SIGACT Symposium on Principles of Programming Languages,pages 393–407. ACM Press, New York, New York, USA, 1995. ISBN 0-89791-692-1. doi: http://doi.acm.org/10.1145/199448.199536. Cited on pages 50,103, and 113.

Ralph E. Johnson, Justin O. Graver, and Laurance W. Zurawski. TS: An op-timizing compiler for Smalltalk. In OOPSLA ’88: Conference proceedingson Object-Oriented Programming Systems, Languages and Applications, pages18–26. ACM, New York, New York, USA, 1988. ISBN 0-89791-284-5. doi:http://doi.acm.org/10.1145/62083.62086. Cited on page 97.

126

http://dx.doi.org/10.1016/S0890-5401(03)00009-9

http://dx.doi.org/10.1016/S0890-5401(03)00009-9

http://doi.acm.org/10.1145/239912.239913

http://doi.acm.org/10.1145/239912.239913

http://doi.acm.org/10.1145/268946.268973

http://doi.acm.org/10.1145/199448.199536

http://doi.acm.org/10.1145/62083.62086

BIBLIOGRAPHY

Neil D. Jones. Flow analysis of lambda expressions (preliminary version). InProceedings of the 8th Colloquium on Automata, Languages and Programming,pages 114–128. Springer-Verlag, London, UK, 1981. ISBN 3-540-10843-2.Cited on page 4.

Neil D. Jones. Computability and Complexity: From a Programming Perspec-tive. MIT Press, Cambridge, Massachusetts, USA, 1997. ISBN 0-262-10064-9.Cited on page xvii.

Neil D. Jones and Nina Bohr. Call-by-value termination in the untyped λ-calculus.Logical Methods in Computer Science, 4(1):1–39, 2008. Cited on page 104.

Neil D. Jones, Carsten K. Gomard, and Peter Sestoft. Partial evaluation andautomatic program generation. Prentice-Hall, Inc., Upper Saddle River, NewJersey, USA, 1993. ISBN 0-13-020249-5. Cited on page 69.

Neil D. Jones and Flemming Nielson. Abstract interpretation: a semantics-basedtool for program analysis. pages 527–636. Oxford University Press, Oxford,UK, 1995. ISBN 0-19-853780-8. Cited on page 18.

Paris C. Kanellakis, Harry G. Mairson, and John C. Mitchell. Unification andML-type reconstruction. In Computational Logic: Essays in Honor of AlanRobinson, pages 444–478. MIT Press, 1991. Cited on page 107.

Assaf J. Kfoury, Harry G. Mairson, Franklyn A. Turbak, and J. B. Wells. Re-lating typability and expressiveness in finite-rank intersection type systems(extended abstract). In ICFP ’99: Proceedings of the fourth ACM SIG-PLAN International Conference on Functional Programming, pages 90–101.ACM, New York, New York, USA, 1999. ISBN 1-58113-111-9. doi: http://doi.acm.org/10.1145/317636.317788. Cited on page 108.

L. Kristiansen and K.-H. Niggl. On the computational complexity of imperativeprogramming languages. Theor. Comput. Sci., 318(1-2):139–161, 2004. ISSN0304-3975. doi: http://dx.doi.org/10.1016/j.tcs.2003.10.016. Cited on page104.

George Kuan and David MacQueen. Efficient type inference using ranked typevariables. In ML ’07: Proceedings of the 2007 Workshop on ML, pages 3–14. ACM, New York, New York, USA, 2007. ISBN 978-1-59593-676-9. doi:http://doi.acm.org/10.1145/1292535.1292538. Cited on page 75.

127

http://doi.acm.org/10.1145/317636.317788

http://doi.acm.org/10.1145/317636.317788

http://dx.doi.org/10.1016/j.tcs.2003.10.016

http://doi.acm.org/10.1145/1292535.1292538

BIBLIOGRAPHY

Richard E. Ladner. The circuit value problem is log space complete for P .SIGACT News, 7(1):18–20, 1975. ISSN 0163-5700. doi: http://doi.acm.org/10.1145/990518.990519. Cited on pages 38 and 44.

Yves Lafont. From proof-nets to interaction nets. In Proceedings of the Workshopon Advances in Linear Logic, pages 225–247. Cambridge University Press,New York, New York, USA, 1995. ISBN 0-521-55961-8. Cited on page 72.

William Landi. Interprocedural Aliasing in the Presence of Pointers. Ph.D. thesis,Rutgers University, 1992a. Cited on pages 101, 103, and 112.

William Landi. Undecidability of static analysis. ACM Lett. Program. Lang.Syst., 1(4):323–337, 1992b. ISSN 1057-4514. doi: http://doi.acm.org/10.1145/161494.161501. Cited on pages 103 and 112.

William Landi and Barbara G. Ryder. Pointer-induced aliasing: a problem tax-onomy. In POPL 1991, pages 93–103. doi: http://doi.acm.org/10.1145/99583.99599. Cited on pages 103 and 112.

William Landi and Barbara G. Ryder. A safe approximate algorithm for interpro-cedural aliasing. In PLDI ’92: Proceedings of the ACM SIGPLAN 1992 Con-ference on Programming Language Design and Implementation, pages 235–248. ACM, New York, New York, USA, 1992. ISBN 0-89791-475-9. doi:http://doi.acm.org/10.1145/143095.143137. Cited on page 22.

William Landi and Barbara G. Ryder. A safe approximate algorithm for in-terprocedural pointer aliasing. In McKinley (2004), pages 473–489. doi:http://doi.acm.org/10.1145/989393.989440. Cited on page 22.

Peter J. Landin. The mechanical evaluation of expressions. The Computer Jour-nal, 6(4):308–320, 1964. Cited on pages xvi and 10.

Julia L. Lawall and Harry G. Mairson. Sharing continuations: Proofnets forlanguages with explicit control. In ESOP ’00: Proceedings of the 9th Euro-pean Symposium on Programming Languages and Systems, pages 245–259.Springer-Verlag, London, UK, 2000. ISBN 3-540-67262-1. Cited on page 70.

Chin Soon Lee, Neil D. Jones, and Amir M. Ben-Amram. The size-change prin-ciple for program termination. In POPL ’01: Proceedings of the 28th ACMSIGPLAN-SIGACT Symposium on Principles of Programming Languages,

128

http://doi.acm.org/10.1145/990518.990519

http://doi.acm.org/10.1145/990518.990519

http://doi.acm.org/10.1145/161494.161501

http://doi.acm.org/10.1145/161494.161501

http://doi.acm.org/10.1145/99583.99599

http://doi.acm.org/10.1145/99583.99599

http://doi.acm.org/10.1145/143095.143137

http://doi.acm.org/10.1145/989393.989440

BIBLIOGRAPHY

pages 81–92. ACM, New York, New York, USA, 2001. ISBN 1-58113-336-7. doi: http://doi.acm.org/10.1145/360204.360210. Cited on page 104.

Daniel Leivant. Stratified functional programs and computational complexity. InPOPL 1993, pages 325–333. doi: http://doi.acm.org/10.1145/158511.158659.Cited on page 104.

Jean-Jacques Levy. Reductions correctes et optimales dans le lambda-calcul.Ph.D. thesis, University of Paris VII, 1978. These d’Etat. Cited on pages 72and 88.

Jean-Jacques Levy. Optimal reductions in the lambda-calculus. In Seldin andHindley (1980), pages 159–191. Cited on page 88.

Harry G. Mairson. Deciding ML typability is complete for deterministic expo-nential time. In POPL 1990, pages 382–401. doi: http://doi.acm.org/10.1145/96709.96748. Cited on pages 75, 86, 93, 96, 105, and 106.

Harry G. Mairson. Quantifier elimination and parametric polymorphism in pro-gramming languages. J. Functional Programming, 2:213–226, 1992a. Cited onpage 107.

Harry G. Mairson. A simple proof of a theorem of Statman. Theor. Comput.Sci., 103(2):387–394, 1992b. ISSN 0304-3975. doi: http://dx.doi.org/10.1016/0304-3975(92)90020-G. Cited on page 67.

Harry G. Mairson. From Hilbert spaces to Dilbert spaces: Context semanticsmade simple. In FST TCS ’02: Proceedings of the 22nd Conference Kanpur onFoundations of Software Technology and Theoretical Computer Science, pages2–17. Springer-Verlag, London, UK, 2002. ISBN 3-540-00225-1. Cited onpage 65.

Harry G. Mairson. Linear lambda calculus and PTIME-completeness. J. Func-tional Program., 14(6):623–633, 2004. ISSN 0956-7968. doi: http://dx.doi.org/10.1017/S0956796804005131. Cited on pages 46, 61, 64, 92, 105, 106,and 115.

Harry G. Mairson. Axiom-sensitive normalization bounds for multiplicative linearlogic. 2006a. Unpublished manuscript. Cited on page 66.

129

http://doi.acm.org/10.1145/360204.360210

http://doi.acm.org/10.1145/158511.158659

http://doi.acm.org/10.1145/96709.96748

http://doi.acm.org/10.1145/96709.96748

http://dx.doi.org/10.1016/0304-3975(92)90020-G

http://dx.doi.org/10.1016/0304-3975(92)90020-G

http://dx.doi.org/10.1017/S0956796804005131

http://dx.doi.org/10.1017/S0956796804005131

BIBLIOGRAPHY

Harry G. Mairson. MLL normalization and transitive closure: circuits, complex-ity, and Euler tours. In GEOCAL (Geometry of Calculation): Implicit Com-putational Complexity. Institut de Mathematique de Luminy, Marseille. 2006b.Cited on pages 46, 66, and 68.

Harry G. Mairson and Kazushige Terui. On the computational complexity of cut-elimination in linear logic. In Carlo Blundo and Cosimo Laneve, editors, Theo-retical Computer Science, 8th Italian Conference, ICTCS 2003, Bertinoro, Italy,October 13-15, 2003, Proceedings, volume 2841 of Lecture Notes in ComputerScience, pages 23–36. Springer, 2003. ISBN 3-540-20216-1. Cited on page 72.

John C. Martin. Introduction to Languages and the Theory of Computation.McGraw-Hill Higher Education, 1997. ISBN 0070408459. Cited on page 95.

David McAllester. On the complexity analysis of static analyses. J. ACM,49(4):512–537, 2002. ISSN 0004-5411. doi: http://doi.acm.org/10.1145/581771.581774. Cited on pages 95 and 104.

Kathryn S. McKinley, editor. SIGPLAN Not., Special Issue: 20 Years of PLDI(1979 - 1999): A Selection, volume 39. ACM, New York, New York, USA,2004. Cited on pages 128 and 136.

David Melski and Thomas Reps. Interconvertibility of a class of set constraintsand context-free-language reachability. Theor. Comput. Sci., 248(1-2):29–98, 2000. ISSN 0304-3975. doi: http://dx.doi.org/10.1016/S0304-3975(00)00049-9. Cited on pages 91, 93, and 95.

Jan Midtgaard. Control-flow analysis of functional programs. Technical ReportBRICS RS-07-18, DAIMI, Department of Computer Science, University ofAarhus, Aarhus, Denmark, 2007. To appear in revised form in ACM Com-puting Surveys. Cited on pages xv, 4, 36, and 102.

Jan Midtgaard and Thomas Jensen. A calculational approach to control-flow anal-ysis by abstract interpretation. In Alpuente and Vidal (2008), pages 347–362.Cited on pages 25 and 57.

Jan Midtgaard and Thomas Jensen. Control-flow analysis of function calls andreturns by abstract interpretation. In ICFP ’09: Proceedings of the ACM SIG-PLAN International Conference on Functional Programming. 2009. To appear.Extended version available as INRIA research report RR-6681. Cited on pages25 and 57.

130

http://doi.acm.org/10.1145/581771.581774

http://doi.acm.org/10.1145/581771.581774

http://dx.doi.org/10.1016/S0304-3975(00)00049-9

http://dx.doi.org/10.1016/S0304-3975(00)00049-9

BIBLIOGRAPHY

Jan Midtgaard and David Van Horn. Subcubic control-flow analysis algorithms.Technical Report 125, Roskilde University, Denmark, 2009. To appear in theSymposium in Honor of Mitchell Wand. Cited on pages 95 and 114.

Matthew Might. Environment analysis of higher-order languages. Ph.D. thesis,Georgia Institute of Technology, Atlanta, Georgia, 2007. Adviser-Olin G. Shiv-ers. Cited on pages 25 and 103.

Matthew Might and Olin Shivers. Environment analysis via ∆CFA. In POPL’06: Conference record of the 33rd ACM SIGPLAN-SIGACT Symposium onPrinciples of Programming Languages, pages 127–140. ACM, New York, NewYork, USA, 2006a. ISBN 1-59593-027-2. doi: http://doi.acm.org/10.1145/1111037.1111049. Cited on pages 25 and 103.

Matthew Might and Olin Shivers. Improving flow analyses via ΓCFA: Abstractgarbage collection and counting. In Proceedings of the 11th ACM InternationalConference on Functional Programming (ICFP 2006), pages 13–25. Portland,Oregon, 2006b. Cited on pages 4, 29, 86, 88, 92, and 114.

Ana Milanova, Atanas Rountev, and Barbara G. Ryder. Parameterized objectsensitivity for points-to analysis for Java. ACM Trans. Softw. Eng. Methodol.,14(1):1–41, 2005. ISSN 1049-331X. doi: http://doi.acm.org/10.1145/1044834.1044835. Cited on pages 99 and 103.

John C. Mitchell. Type systems for programming languages. In van Leeuwen(1990), pages 365–458. Cited on page 107.

Peter Møller Neergaard. Complexity Aspects of Programming Language Design:From Logspace to Elementary Time via Proofnets and Intersection Types. Ph.D.thesis, Brandeis University, Waltham, Massachusetts, USA, 2004. Cited onpages 72 and 108.

Peter Møller Neergaard and Harry G. Mairson. Types, potency, and idempo-tency: why nonlinearity and amnesia make a type system work. In ICFP’04: Proceedings of the ninth ACM SIGPLAN International Conference onFunctional Programming, pages 138–149. ACM Press, New York, New York,USA, 2004. ISBN 1-58113-905-5. doi: http://doi.acm.org/10.1145/1016850.1016871. Cited on pages 93, 105, and 108.

131

http://doi.acm.org/10.1145/1111037.1111049

http://doi.acm.org/10.1145/1111037.1111049

http://doi.acm.org/10.1145/1044834.1044835

http://doi.acm.org/10.1145/1044834.1044835

http://doi.acm.org/10.1145/1016850.1016871

http://doi.acm.org/10.1145/1016850.1016871

BIBLIOGRAPHY

Christian Mossin. Exact flow analysis. In SAS ’97: Proceedings of the 4th Interna-tional Symposium on Static Analysis, pages 250–264. Springer-Verlag, London,UK, 1997a. ISBN 3-540-63468-1. Cited on pages 52 and 87.

Christian Mossin. Flow Analysis of Typed Higher-Order Programs. Ph.D. thesis,DIKU, University of Copenhagen, 1997b. Cited on pages 25 and 72.

Christian Mossin. Higher-order value flow graphs. Nordic J. of Computing,5(3):214–234, 1998. ISSN 1236-6064. Cited on pages 31, 51, and 113.

Steven S. Muchnick and Neil D. Jones, editors. Program Flow Analysis: Theoryand Applications. Prentice Hall, 1981. Cited on pages 3 and 27.

Robert Muth and Saumya Debray. On the complexity of flow-sensitive dataflowanalyses. In POPL ’00: Proceedings of the 27th ACM SIGPLAN-SIGACT Sym-posium on Principles of Programming Languages, pages 67–80. ACM, NewYork, New York, USA, 2000. ISBN 1-58113-125-9. doi: http://doi.acm.org/10.1145/325694.325704. Cited on pages 103 and 112.

Alan Mycroft, editor. Static Analysis, Second International Symposium, SAS’95,Glasgow, UK, September 25-27, 1995, Proceedings, volume 983 of LectureNotes in Computer Science. Springer, 1995. ISBN 3-540-60360-3. Cited onpages 122 and 124.

Eugene M. Myers. A precise inter-procedural data flow algorithm. In POPL ’81:Proceedings of the 8th ACM SIGPLAN-SIGACT Symposium on Principles ofProgramming Languages, pages 219–230. ACM, New York, New York, USA,1981. ISBN 0-89791-029-X. doi: http://doi.acm.org/10.1145/567532.567556.Cited on page 103.

Radford Neal. The computational complexity of taxonomic inference. 1989.Unpublished manuscript. ftp://ftp.cs.utoronto.ca/pub/radford/taxc.ps. Cited onpage 95.

Flemming Nielson and Hanne Riis Nielson. Infinitary control flow analysis: acollecting semantics for closure analysis. In POPL 1997, pages 332–345. doi:http://doi.acm.org/10.1145/263699.263745. Cited on pages 25, 103, and 113.

Flemming Nielson, Hanne Riis Nielson, and Chris Hankin. Principles of ProgramAnalysis. Springer-Verlag New York, Inc., Secaucus, New Jersey, USA, 1999.

132

http://doi.acm.org/10.1145/325694.325704

http://doi.acm.org/10.1145/325694.325704

http://doi.acm.org/10.1145/567532.567556

ftp://ftp.cs.utoronto.ca/pub/radford/taxc.ps

http://doi.acm.org/10.1145/263699.263745

BIBLIOGRAPHY

ISBN 3540654100. Cited on pages xvii, 3, 9, 16, 18, 20, 21, 24, 34, 35, 74,and 76.

OOPSLA 1996. OOPSLA ’96: Proceedings of the 11th ACM SIGPLAN Confer-ence on Object-Oriented Programming, Systems, Languages, and Applications.ACM, New York, New York, USA, 1996. ISBN 0-89791-788-X. Cited on pages118 and 122.

Nicholas Oxhøj, Jens Palsberg, and Michael I. Schwartzbach. Making type infer-ence practical. In ECOOP ’92: Proceedings of the European Conference onObject-Oriented Programming, pages 329–349. Springer-Verlag, London, UK,1992. ISBN 3-540-55668-0. Cited on page 99.

Jens Palsberg. Closure analysis in constraint form. ACM Trans. Program. Lang.Syst., 17(1):47–62, 1995. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/200994.201001. Cited on page 102.

Jens Palsberg and Patrick O’Keefe. A type system equivalent to flow analysis.ACM Trans. Program. Lang. Syst., 17(4):576–599, 1995. ISSN 0164-0925.doi: http://doi.acm.org/10.1145/210184.210187. Cited on page 25.

Jens Palsberg and Christina Pavlopoulou. From polyvariant flow information tointersection and union types. J. Funct. Program., 11(3):263–317, 2001. ISSN0956-7968. doi: http://dx.doi.org/10.1017/S095679680100394X. Cited onpages 25 and 72.

Jens Palsberg and Michael I. Schwartzbach. Object-oriented type inference. InOOPSLA ’91: Conference proceedings on Object-Oriented Programming Sys-tems, Languages, and Applications, pages 146–161. ACM, New York, NewYork, USA, 1991. ISBN 0-201-55417-8. doi: http://doi.acm.org/10.1145/117954.117965. Cited on pages 97 and 98.

Jens Palsberg and Michael I. Schwartzbach. Safety analysis versus type inference.Inf. Comput., 118(1):128–141, 1995. ISSN 0890-5401. doi: http://dx.doi.org/10.1006/inco.1995.1058. Cited on page 57.

Christos H. Papadimitriou. Computational Complexity. Addison-Wesley, Read-ing, Massachusetts, USA, 1994. ISBN 0201530821. Cited on pages xvi, 25,26, and 52.

133

http://doi.acm.org/10.1145/200994.201001

http://doi.acm.org/10.1145/200994.201001

http://doi.acm.org/10.1145/210184.210187

http://dx.doi.org/10.1017/S095679680100394X

http://doi.acm.org/10.1145/117954.117965

http://doi.acm.org/10.1145/117954.117965

http://dx.doi.org/10.1006/inco.1995.1058

http://dx.doi.org/10.1006/inco.1995.1058

BIBLIOGRAPHY

Michel Parigot. λµ-calculus: An algorithmic interpretation of classical natural de-duction. In Logic Programming and Automated Reasoning,International Con-ference LPAR’92, St. Petersburg, Russia, July 15-20, 1992, Proceedings, vol-ume 624 of Lecture Notes in Computer Science, pages 190–201. Springer, 1992.ISBN 3-540-55727-X. Cited on page 70.

Lawrence C. Paulson. ML for the Working Programmer. Cambridge UniversityPress, second edition, 1996. ISBN 052156543X. Cited on page xvi.

Frank Pfenning. On the undecidability of partial polymorphic type reconstruction.Fundam. Inf., 19(1-2):185–199, 1993. ISSN 0169-2968. Cited on page 109.

POPL 1990. Proceedings of the 17th ACM SIGPLAN-SIGACT Symposium onPrinciples of Programming Languages. ACM, New York, New York, USA,1990. ISBN 0-89791-343-4. Cited on pages 123 and 129.




POPL 1998. Proceedings of the 25th ACM SIGPLAN-SIGACT Symposium onPrinciples of Programming Languages. ACM, New York, New York, USA,1998. ISBN 0-89791-979-3. Cited on pages 118, 121, and 126.

POPL 2008. Proceedings of the 35th annual ACM SIGPLAN-SIGACT Symposiumon Principles of Programming Languages. ACM, New York, New York, USA,2008. ISBN 978-1-59593-689-9. Cited on pages 120 and 137.

G. Ramalingam. The undecidability of aliasing. ACM Trans. Program. Lang.Syst., 16(5):1467–1471, 1994. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/186025.186041. Cited on page 103.

134

http://doi.acm.org/10.1145/186025.186041

http://doi.acm.org/10.1145/186025.186041

BIBLIOGRAPHY

Laurent Regnier. Lambda calcul et reseaux. Ph.D. thesis, University of Paris VII,1992. Cited on page 72.

Thomas W. Reps. On the sequential nature of interprocedural program-analysisproblems. Acta Informatica, 33(8):739–757, 1996. Cited on pages 10, 91,and 94.

John C. Reynolds. Definitional interpreters for higher-order programming lan-guages. In ACM ’72: Proceedings of the ACM annual conference, pages 717–740. ACM, New York, New York, USA, 1972. doi: http://doi.acm.org/10.1145/800194.805852. Republished in (Reynolds 1998). Cited on pages xvi,9, and 135.

John C. Reynolds. Towards a theory of type structure. In Programming Sympo-sium, Proceedings Colloque sur la Programmation, pages 408–423. Springer-Verlag, London, UK, 1974. ISBN 3-540-06859-7. Cited on page 109.

John C. Reynolds. Definitional interpreters for higher-order programming lan-guages. Higher-Order and Symbolic Computation, 11(4):363–397, 1998. Orig-inally published in (Reynolds 1972). Cited on pages xvi and 135.

Henry G. Rice. Classes of recursively enumerable sets and their decision prob-lems. Trans. Amer. Math. Soc., 74:358–366, 1953. Cited on page 3.

N. Rinetzky, G. Ramalingam, M. Sagiv, and E. Yahav. On the complexityof partially-flow-sensitive alias analysis. ACM Trans. Program. Lang. Syst.,30(3):1–28, 2008. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/1353445.1353447. Cited on pages 99 and 103.

J. Alan Robinson. A machine-oriented logic based on the resolution principle. J.ACM, 12(1):23–41, 1965. ISSN 0004-5411. doi: http://doi.acm.org/10.1145/321250.321253. Cited on pages 107 and 109.

Wojciech Rytter. Fast recognition of pushdown automaton and context-free lan-guages. Inf. Control, 67(1-3):12–22, 1985. ISSN 0019-9958. doi: http://dx.doi.org/10.1016/S0019-9958(85)80024-3. Cited on page 95.

Jonathan P. Seldin and J. Roger Hindley, editors. To H. B. Curry: Essays on Com-binatory Logic, Lambda Calculus and Formalism. Academic Press, London,1980. Cited on pages 126 and 129.

135

http://doi.acm.org/10.1145/800194.805852

http://doi.acm.org/10.1145/800194.805852

http://doi.acm.org/10.1145/1353445.1353447

http://doi.acm.org/10.1145/1353445.1353447

http://doi.acm.org/10.1145/321250.321253

http://doi.acm.org/10.1145/321250.321253

http://dx.doi.org/10.1016/S0019-9958(85)80024-3

http://dx.doi.org/10.1016/S0019-9958(85)80024-3

BIBLIOGRAPHY

Damien Sereni. Termination analysis and call graph construction for higher-orderfunctional programs. In ICFP’07, pages 71–84. doi: http://doi.acm.org/10.1145/1291151.1291165. Cited on pages 103, 104, and 105.

Damien Sereni and Neil D. Jones. Termination analysis of higher-order functionalprograms. In Kwangkeun Yi, editor, Programming Languages and Systems,Third Asian Symposium, APLAS 2005, Tsukuba, Japan, November 2-5, 2005,Proceedings, volume 3780 of Lecture Notes in Computer Science, pages 281–297. Springer, 2005. ISBN 3-540-29735-9. Cited on page 104.

Peter Sestoft. Replacing function parameters by global variables. Master’s thesis,DIKU, University of Copenhagen, Denmark, 1988. Master’s thesis no. 254.Cited on pages 4 and 25.

Peter Sestoft. Replacing function parameters by global variables. In FPCA ’89:Proceedings of the fourth International Conference on Functional Program-ming Languages and Computer Architecture, pages 39–53. ACM Press, NewYork, New York, USA, 1989. ISBN 0-89791-328-0. doi: http://doi.acm.org/10.1145/99370.99374. Cited on pages 4 and 25.

Claude E. Shannon. A mathematical theory of communication. Bell System Tech-nical Journal, 27, 1948. Cited on page 22.

Olin Shivers. Control flow analysis in Scheme. In PLDI ’88: Proceedings of theACM SIGPLAN 1988 Conference on Programming Language Design and Im-plementation, pages 164–174. ACM, New York, New York, USA, 1988. ISBN0-89791-269-1. doi: http://doi.acm.org/10.1145/53990.54007. Cited on pages4, 31, 73, and 74.

Olin Shivers. Control-flow analysis of higher-order languages. Ph.D. thesis,Carnegie Mellon University, Pittsburgh, PA, USA, 1991. Cited on pages 4,25, 74, 97, and 103.

Olin Shivers. Higher-order control-flow analysis in retrospect: lessons learned,lessons abandoned. In McKinley (2004), pages 257–269. doi: http://doi.acm.org/10.1145/989393.989421. Cited on pages 49, 70, 74, and 88.

Dorai Sitaram. Teach Yourself Scheme in Fixnum Days. 2004. Published on-line: http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html. Citedon page xvi.

136

http://doi.acm.org/10.1145/1291151.1291165

http://doi.acm.org/10.1145/1291151.1291165

http://doi.acm.org/10.1145/99370.99374

http://doi.acm.org/10.1145/99370.99374

http://doi.acm.org/10.1145/53990.54007

http://doi.acm.org/10.1145/989393.989421

http://doi.acm.org/10.1145/989393.989421

http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html

BIBLIOGRAPHY

Morten Heine Sørensen and Pawel Urzyczyn. Lectures on the Curry-Howard Iso-morphism, volume 149 of Studies in Logic and the Foundations of Mathematics.Elsevier Science Inc., New York, New York, USA, 2006. ISBN 0444520775.Cited on pages xvi, 59, and 61.

Fausto Spoto and Thomas Jensen. Class analyses as abstract interpretations oftrace semantics. ACM Trans. Program. Lang. Syst., 25(5):578–630, 2003. ISSN0164-0925. doi: http://doi.acm.org/10.1145/937563.937565. Cited on page 98.

Richard Statman. The typed λ-calculus is not elementary recursive. Theor. Com-put. Sci., 9:73–81, 1979. Cited on pages 52, 67, and 114.

Paul A. Steckler and Mitchell Wand. Lightweight closure conversion. ACM Trans.Program. Lang. Syst., 19(1):48–86, 1997. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/239912.239915. Cited on page 92.

Bjarne Steensgaard. Points-to analysis in almost linear time. In POPL ’96: Pro-ceedings of the 23rd ACM SIGPLAN-SIGACT Symposium on Principles of Pro-gramming Languages, pages 32–41. ACM, New York, New York, USA, 1996.ISBN 0-89791-769-3. doi: http://doi.acm.org/10.1145/237721.237727. Citedon pages 102 and 107.

Yan Mei Tang and Pierre Jouvelot. Separate abstract interpretation for control-flow analysis. In TACS ’94: Proceedings of the International Conference onTheoretical Aspects of Computer Software, pages 224–243. Springer-Verlag,London, UK, 1994. ISBN 3-540-57887-0. Cited on page 25.

Kazushige Terui. On the complexity of cut-elimination in linear logic. 2002.Invited talk at LL2002 (LICS2002 affiliated workshop), Copenhagen. Cited onpage 66.

Jerzy Tiuryn. Type inference problems: a survey. In MFCS ’90: Proceed-ings on Mathematical Foundations of Computer Science 1990, pages 105–120.Springer-Verlag New York, Inc., New York, New York, USA, 1990. ISBN0-387-52953-5. Cited on page 107.

Sam Tobin-Hochstadt and Matthias Felleisen. The design and implementation ofTyped Scheme. In POPL 2008, pages 395–406. doi: http://doi.acm.org/10.1145/1328438.1328486. Cited on page 109.

137

http://doi.acm.org/10.1145/937563.937565

http://doi.acm.org/10.1145/239912.239915

http://doi.acm.org/10.1145/239912.239915

http://doi.acm.org/10.1145/237721.237727

http://doi.acm.org/10.1145/1328438.1328486

http://doi.acm.org/10.1145/1328438.1328486

BIBLIOGRAPHY

Jeffrey D. Ullman and Allen van Gelder. Parallel complexity of logical queryprograms. In SFCS ’86: Proceedings of the 27th Annual Symposium onFoundations of Computer Science (SFCS 1986), pages 438–454. IEEE Com-puter Society, Washington, DC, USA, 1986. ISBN 0-8186-0740-8. doi:http://dx.doi.org/10.1109/SFCS.1986.40. Cited on page 93.

Paweł Urzyczyn. Type reconstruction in Fω. Mathematical. Structures in Comp.Sci., 7(4):329–358, 1997. ISSN 0960-1295. doi: http://dx.doi.org/10.1017/S0960129597002302. Cited on page 109.

Steffen van Bakel. Complete restrictions of the intersection type discipline. Theor.Comput. Sci., 102(1):135–163, 1992. ISSN 0304-3975. doi: http://dx.doi.org/10.1016/0304-3975(92)90297-S. Cited on page 108.

David Van Horn and Harry G. Mairson. Relating complexity and precision incontrol flow analysis. In ICFP’07, pages 85–96. doi: http://doi.acm.org/10.1145/1291151.1291166. Cited on page xviii.

David Van Horn and Harry G. Mairson. Deciding kCFA is complete for EXP-TIME. In Proceedings of the 2008 ACM SIGPLAN International Conferenceon Functional Programming, Victoria, BC, Canada, September 22–24, pages275–282. 2008a. Cited on page xviii.

David Van Horn and Harry G. Mairson. Flow analysis, linearity, and PTIME. InAlpuente and Vidal (2008), pages 255–269. Cited on pages xviii and 95.

J. van Leeuwen, editor. Handbook of Theoretical Computer Science (Vol. B):Formal Models and Semantics. MIT Press, Cambridge, Massachusetts, USA,1990. ISBN 0-444-88074-7. Cited on pages 118 and 131.

Virginia Vassilevska. Efficient algorithms for clique problems. Inf. Process. Lett.,109(4):254–257, 2009. ISSN 0020-0190. doi: http://dx.doi.org/10.1016/j.ipl.2008.10.014. Cited on page 95.

Jan Vitek, R. Nigel Horspool, and James S. Uhl. Compile-time analysis of object-oriented programs. In CC ’92: Proceedings of the 4th International Confer-ence on Compiler Construction, pages 236–250. Springer-Verlag, London, UK,1992. ISBN 3-540-55984-1. Cited on page 99.

Mitchell Wand. A simple algorithm and proof for type inference. Fundam. In-form., 10:115–122, 1987. Cited on pages 107 and 109.

138


http://dx.doi.org/10.1017/S0960129597002302

http://dx.doi.org/10.1017/S0960129597002302

http://dx.doi.org/10.1016/0304-3975(92)90297-S

http://dx.doi.org/10.1016/0304-3975(92)90297-S

http://doi.acm.org/10.1145/1291151.1291166

http://doi.acm.org/10.1145/1291151.1291166

http://dx.doi.org/10.1016/j.ipl.2008.10.014

http://dx.doi.org/10.1016/j.ipl.2008.10.014

BIBLIOGRAPHY

J. B. Wells. Typability and type checking in System F are equivalent and unde-cidable. Annals of Pure and Applied Logic, 98:111–156, 1999. Cited on page109.

J. B. Wells, Allyn Dimock, Robert Muller, and Franklyn Turbak. A calculus withpolymorphic and polyvariant flow types. J. Funct. Program., 12(3):183–227,2002. ISSN 0956-7968. doi: http://dx.doi.org/10.1017/S0956796801004245.Cited on page 72.

Robert P. Wilson and Monica S. Lam. Efficient context-sensitive pointer anal-ysis for C programs. In PLDI ’95: Proceedings of the ACM SIGPLAN 1995Conference on Programming Language Design and Implementation, pages 1–12. ACM, New York, New York, USA, 1995. ISBN 0-89791-697-2. doi:http://doi.acm.org/10.1145/207110.207111. Cited on page 103.

Andrew K. Wright and Suresh Jagannathan. Polymorphic splitting: an effectivepolyvariant flow analysis. ACM Trans. Program. Lang. Syst., 20(1):166–207,1998. ISSN 0164-0925. doi: http://doi.acm.org/10.1145/271510.271523. Citedon pages 4, 29, 86, and 103.

Uri Zwick. A slightly improved sub-cubic algorithm for the all pairs shortest pathsproblem with real edge lengths. Algorithmica, 46(2):181–192, 2006. ISSN0178-4617. doi: http://dx.doi.org/10.1007/s00453-005-1199-1. Cited on page95.

139

http://dx.doi.org/10.1017/S0956796801004245

http://doi.acm.org/10.1145/207110.207111

http://doi.acm.org/10.1145/271510.271523

http://dx.doi.org/10.1007/s00453-005-1199-1

Colophon

This dissertation was produced using Free Software on a digital computer. Thedocument was composed in GNU Emacs and typeset using LATEX and the Brandeisdissertation class by Peter Møller Neergaard. The Times font family is used fortext and the Computer Modern font family, designed by Donald E. Knuth, is usedfor mathematics. Some figures were typeset using the METAPOST language byJohn D. Hobby and sequent calculus proofs were typeset using Didier Remy’sMath Paragraph for Typesetting Inference Rules.

This dissertation is Free Software. It is released under the terms of the AcademicFree License version 3.0. Source code is available:

http://svn.lambda-calcul.us/dissertation/

Machine wash cold in commercial size, front loading machine, gentle cycle, mildpowder detergent. Rinse thoroughly. Tumble dry low in large capacity dryer. Donot iron. Do not dry clean. Do not bleach. Secure all velcro closures.

Û�²¨Ì λL

http://svn.lambda-calcul.us/dissertation/

Documents

The Complexity of Flow Analysis in Higher-Order Languages · 2013-11-20 · The Complexity of Flow Analysis in Higher-Order Languages A Dissertation Presented to The Faculty of the