Jones N.D.Partial evaluation and automatic program generation.1999

312 Program Analysis

That is, EvenOdd is a complete lattice: every set S of elements from EvenOdd has a least upper bound F S and a greatest lower bound uS. Provided that the abstract operations + and are monotonic (and they are), there is therefore a least solution to the equation de ning g# (and indeed any abstract function) [261]. Recall that least means most informative. Since the lattice has nite height, this solution can even be found in nite time, which is important since program analyses should always terminate. For this reason the abstract values are usually required to form a lattice of nite height.

In the case of g# above, a tabulation of the (argument, result) pairs for the four possible argument values shows that g# is the identity on EvenOdd:

g#(X) = > if X = >

=even if X = even

=odd if X = odd

=? if X = ?

Abstract addition and multiplication on EvenOdd = f?; even; odd; >g is de ned by the tables below. Notice that these are extensions of the tables given at the beginning of the section.

In summary, we have seen that expressions can be evaluated abstractly, for instance to know whether the result of ordinary evaluation will be even or odd. We have also seen that because of conditional expressions and recursively de ned functions, we need two more abstract values > and ?, which correspond to `no information' and `not de ned'.

15.1.3Abstraction and concretization mappings

Informally, the abstract value even represents all even numbers, odd represents all odd numbers, > represents all numbers, and ? represents no numbers. Also, if a number is represented by some abstract value s 2 EvenOdd, then also by every abstract value t which is greater than s, that is, which is less precise than s.

These notions can be formalized using an abstraction function and a concretization function . Let N = f0; 1; . . .g be the set of natural numbers, and let }(N ) be the powerset of N , that is, the set of subsets of N , partially ordered by set inclusion .

Then the concretization function : EvenOdd ! }(N ) maps an abstract value s to the set (s) of concrete numbers represented by s. Conversely, the abstraction

Abstract interpretation 313

function : }(N) ! EvenOdd maps a set V of numbers to the (smallest) abstract value (V ) representing all numbers in the set.

The abstraction and concretization functions must (1) be monotonic, and further satisfy the following requirements:

(2)8s 2 EvenOdd: ( (s)) = s

(3)8V 2 }(N ): ( (V )) V

The monotonicity requirement (1) means that a larger abstract value represents a larger set of concrete values. Requirement (2) means that every abstract value represents something; there are no super uous abstract values. Requirement (3) means that abstracting and then concretizing a set V of concrete values gives a set containing V . In other words, the abstraction of V safely represents all elements of V .

In the EvenOdd example, the concretization function is

Using and we can now de ne what it means for an abstract function f# : EvenOdd ! EvenOdd to safely abstract a concrete function f : N ! N. Namely, let n 2 N be a concrete number; it is described by the abstract value (fng). The requirement on f# is that the concrete result f(n) is safely represented by the abstract result f#( (fng)):

8n 2 N : f(n) 2 (f# ( (fng)))

15.1.4The Scheme0 binding-time analysis as an abstract interpretation

Looking back on the binding-time analysis for Scheme0 presented in Section 5.2, we nd that it is a very simple abstract interpretation. Consider the expression x+8 and assume x is dynamic (clearly the constant 8 is static). That is, x has binding time D and 8 has binding time S, so the entire expression has binding time D + S which is D.

In Scheme0, every expression having a dynamic subexpression is itself dynamic, so all abstract operators are very simple: the abstract value of an expression is the least upper bound of the abstract values of all subexpressions. In particular, the abstract evaluation of a function application (f e) does not use any abstraction of f, only the binding time of e. Although the analysis is very simple, it gives reasonably good results because Scheme0 is a rst-order language and has no partially

Closure analysis 315

The purpose of a closure analysis is to compute this information without actually executing the program. That is, a closure analysis computes an approximation to the set of functions that e1 may evaluate to [247].

First we present the components of the closure analysis, then we see how it can be seen as an abstract interpretation.

15.2.1The higher-order language Scheme1

We describe a closure analysis for the higher-order functional language Scheme1 used in Chapter 10. Recall that a Scheme1 program pgm has the form:

Each function body bodyi is a Scheme1 expression. The syntax of expressions is shown in Figure 10.1 on page 206. All lambda abstractions and the corresponding lambda-bound variables are labelled by a superscript `. For brevity we say `lambda' instead of `lambda abstraction', and write ( x`.e) instead of (lambda` (x) e) in this chapter.

We distinguish three kinds of variables: function variables xij , lambda variables x`, and let variables x. A function variable xij is a formal parameter of a named function, a lambda variable x` is bound by a lambda abstraction, and a let variable is bound in a let expression. All variable names must be distinct. The arguments and results of the goal function and of base functions must be base values.

15.2.2Closure analysis functions

Assume that a Scheme1 program pgm, of the form shown above, is given. We want to know which lambdas can be applied in an application (e1 e2). Therefore we need to know which lambdas e1 can evaluate to. An important step in that direction is to nd the set of lambdas that variables and applications can evaluate to. The closure analysis is based on two maps and giving these two kinds of information, where we identify a lambda expression x`.e with its label `. Formally, let

The intended meanings of and are

316 Program Analysis

As before, we must satisfy ourselves with approximate information, so we actually just require that the set fi contains all the lambdas that ei can evaluate to, and similarly for the . Thus the safety requirement is: closure analysis of expression e1 must tell us at least all lambdas that e1 can evaluate to (and possibly some more). Note that by the restrictions the goal function, f1 = fg and f1 = fg.

In the analysis, the label ` abstracts the set of all the closures that can be built (at run time) from the expression x`.e.

Example 15.1 Consider the following program (the superscript ` is a lambda label):

(define (f x n) (( k`1 .k x) (if (even n) ( y`2 .y*y) ( z`3 .2*z))))

We have k = f`2; `3g since the expression (if . . . ) can evaluate to y`2 .y*y as well as z`3 .2*z. Also, v = fg for all other variables v, f = fg, and ` = fg for all labels `.

Now consider the equivalent but more complicated program:

(define (f x n) (g (( x1`1 . k`2 .k x1) x)

(h (even n) ( x3`3 .x3*x3) ( x4`4.2*x4)))) (define (g k1 z) (k1 z))

(define (h b c a) (if b c a))

Here we have k1 = `1 = f`2g, z = h = f`3; `4g, c = f`3g, a = f`4g, v = fg for all other variables v, ` = fg for all other labels `, and f = g = fg. 2

To compute and in general, we de ne two analysis functions Pe and Pv , where

Pe is called the closure analysis function and Pv is called the closure propagation function. The closure analysis function Pe is de ned in Figure 15.1.

The intention is that Pe[[e]] is (a superset of) the set of lambdas that e may evaluate to. The variable environment is de ned using the analysis function Pv , to be shown shortly.

The equations de ning Pe in Figure 15.1 are justi ed as follows. A constant can evaluate to no lambda. A variable x can evaluate only to those lambdas it can be bound to, that is, ( x). A conditional can evaluate only to those lambdas that the two branches can evaluate to. An application of a named function fi can evaluate to those lambdas that the function's body can evaluate to, that is, ( fi). A base function must return a base value and so cannot evaluate to a lambda. The lambda expression labelled ` can evaluate only to itself. The application (e1 e2) can evaluate to those lambdas which an application of lambda ` can, when x`.. . .

is a possible value of e1. A let expression can evaluate to those lambdas that its body can evaluate to.

Closure analysis 317

Figure 15.1: The closure analysis function Pe.

The closure propagation function Pv is shown in Figure 15.2. The application Pv [[e]] y is (a superset of) the set of lambdas that variable y can be bound to in an evaluation of e. If y is a function variable xij, it can be bound to a lambda only in an application of function fi. Similarly, if y is a lambda variable x`, it can be bound to a lambda only in an application of the lambda expression x`.. . .

labelled `. If y is a let variable, it can get bound only in the corresponding let.

Figure 15.2: The closure propagation function Pv.

The equations de ning function Pv in Figure 15.2 are therefore justi ed as follows. Evaluating a constant or a variable cannot bind variable y. Evaluating a conditional can do those bindings that any of the three subexpressions can do. Applying a named function fi binds y if it is one of the parameters xij of fi. In

318 Program Analysis

this case, y can get bound to whatever lambdas the argument ej can evaluate to. Moreover, y can get bound by evaluating any of the argument expressions. In a lambda abstraction, y can get bound in the body e. A lambda application (e1 e2) binds y if it is a lambda variable x` and e1 can evaluate to the lambda labelled `. In this case, y can get bound to whatever lambdas the argument e2 can evaluate to. Finally, a let expression binds y if y is the same as the variable x being bound.

15.2.3Closure analysis of a program

Closure analysis of a program should produce a safe description ( , ) which is as precise as possible. The description is obtained as the least solution to a set of equations specifying the safety requirement.

As described above, should map a named function fi to the set of lambdas that its body can evaluate to, that is, Pe[[bodyi]] . Similarly, it should map a lambda label ` to the set of lambdas that the body e of x`.e can evaluate to, that is, Pe[[e]] .

The map should map a function variable x to the set of lambdas that it can be bound to, that is, the union of Pv[[bodyi]] x over all function bodies bodyi. Similarly, should map a lambda variable x` to the set of lambdas it can be bound to, that is, the union of Pv [[bodyi ]] x` over all function bodies bodyi ; and likewise for the let-variables.

These requirements are summarized by the equations below:

S

S

Any solution to these equations is a safe analysis result. The least solution is the most precise, safe solution.

15.2.4Closure analysis as an abstract interpretation

The closure analysis as described above can be understood as an abstract interpretation. An abstract value L 2 LabelSet is a set of labels. The abstract values are ordered by inclusion: L1 is smaller than L2 if and only if L1 L2. This makes LabelSet a lattice and is very reasonable, intuitively: a smaller lambda label set is more informative, since it says: only these lambdas are possible.

Abstract interpretation of a program produces a description ( , ) 2 ResEnv VarEnv. Recall that ResEnv and VarEnv are mappings (from function and variable names) to label sets, so the set ResEnv VarEnv of descriptions can be ordered

Higher-order binding-time analysis 319

by pointwise inclusion, which makes it a lattice.

To roughly formalize the abstraction and concretization functions, we must de-ne the set Scheme1Val of values that can appear in an ordinary Scheme1 evaluation. This is the set of ( rst-order) Scheme0 values, extended with closure objects:

It is clear that and are monotonic, and not hard to see that they also satisfy requirements (2) and (3) on abstraction and concretization functions.

15.3Higher-order binding-time analysis

Using the closure analysis, the rst-order Scheme0 binding-time analysis from Section 5.2 can be extended to a higher-order binding-time analysis for Scheme1. This gives a monovariant binding-time analysis without partially static structures.

In Section 10.1.4 we discussed three problems with binding-time analysis for Scheme1. Problem (1) is the handling of lambda applications (e1 e2). To solve this we use the closure analysis from Section 15.2 and let Pe[[e1]], simply, stand for the set of lambdas that e1 may evaluate to.

Problem (2) is the detection of lambdas in dynamic contexts. If a lambda x`.e may appear in a dynamic context, then code must be generated for the lambda, so x` must be dynamic and its body e is in a dynamic context. To detect lambdas in dynamic contexts we introduce a new map and a new analysis function Bd (in addition to the maps and and functions Be and Bv known from the Scheme0 binding-time analysis).

Problem (3) is the binding-time analysis of let. In this presentation we use the conservative rule suggested in Section 10.1.4. This is unavoidable if the specializer does not use continuation-based reduction (Section 10.5). If the specializer uses continuation-based reduction, then we might use instead the more liberal rule in Section 10.5.5.

320Program Analysis

15.3.1Binding-time analysis maps

As in the Scheme0 binding-time analysis, the binding-time domain is BindingTime = fS; Dg with S < D. The analysis uses three maps , , and , whose intended meanings are

Thus maps a lambda to the binding time of the result of applying it, and is a binding-time environment that maps a variable (whether bound by a named function, a lambda, or a let), to its binding time. The use of these maps is similar to that of and in the closure analysis above. The map is used to record the lambdas that may appear in dynamic contexts.

15.3.2Binding-time analysis functions

The analysis consists of a binding-time analysis function Be and a binding-time propagation function Bv , akin to the functions Be and Bv in the Scheme0 bindingtime analysis. In addition, there is a context propagation function Bd for detection of lambdas in dynamic contexts.

An application Be[[e]] of the Be function nds the binding time of expression e in binding-time environment . The Be function is de ned in Figure 15.3. Equations one, two, three and ve are explained as for Scheme0. Equation four (function call) states that the result of a function call is dynamic if the called function's body is. The binding time can no longer be determined from the arguments, since a static argument may be a partially static lambda containing free dynamic variables. Equation six states that a lambda expression is dynamic if it may appear in a dynamic context, and static otherwise. Equation seven says that the binding time of a higher-order application (e1 e2) is dynamic if e1 is, or if any lambda that e1 can evaluate to gives a dynamic result when applied. Equation eight says that the binding time of a let expression is dynamic if the bound expression e1 or the body e is.

An application Bv[[e]] y nds the binding time of the values assigned to variable y during evaluation of expression e, where y may be a function variable xij, a lambda variable x`, or a let variable x. The Bv function is de ned in Figure 15.4 and is very similar in structure and purpose to function Pv in the closure analysis.

An application Bdd[[e]] `t returns the context (S or D) of lambda x`.. . .