A Functional Perspective on SSA Optimisation Algorithms

Transcription

1 COCV 03 Preliminary Version A Functional Perspective on SSA Optimisation Algorithms Manuel M. T. Chakravarty 1, Gabriele Keller 1 and Patryk Zadarnowski 1 School of Computer Science and Engineering University of New South Wales Sydney, Australia Abstract The static single assignment (SSA) form is central to a range of optimisation algorithms relying on data flow information, and hence, to the correctness of compilers employing those algorithms. It is well known that the SSA form is closely related to lambda terms (i.e., functional programs), and, considering the large amount of energy expended on theories and frameworks for formal reasoning in the lambda calculus, it seems only natural to leverage this connection to improve our capabilities to reason about compiler optimisations. In this paper, we discuss a new formalisation of the mapping from SSA programs to a restricted form of lambda terms, called administrative normal form (ANF). We conjecture that this connection improves our ability to reason about SSA-based optimisation algorithms and provide a first data point by presenting an ANF variant of a well known SSA-based conditional constant propagation algorithm. 1 Introduction The static single assignment (SSA) form is a popular intermediate representation for compiler optimisations [7], and hence, of considerable significance when it comes to reasoning about the correctness of those optimisations. Unfortunately, a formal treatment of the semantics of SSA programs and SSAbased optimisation algorithms is complicated due to, the so-called φ-functions, which control the merging of data flow edges entering code blocks [4]. Kelsey [12] and Appel [3,2] pointed to a correspondence between programs in SSA form and lambda terms (i.e., functional programs). We believe that this correspondence can be leveraged to simplify reasoning about compiler optimisations that hitherto were based on the SSA form. In particular, we 1 {chak,keller,patrykz}@cse.unsw.edu.au This is a preliminary version. The final version will be published in Electronic Notes in Theoretical Computer Science URL:

2 suggest that intermediate forms based on the lambda calculus lead to clearer algorithms, which we expect to positively impact the correctness of concrete implementations, even if they are not formally verified. In this paper, we concentrate on a restricted form of lambda terms, called administrative normal form (ANF) [8], as they have a more clearly defined operational interpretation than general lambda terms. Kelsey [12] related the SSA form to a different form of restricted lambda terms, called continuation passing style (CPS). However, Flanagan et al. [8,17] showed that, for data flow analysis, there is no real advantage to using CPS over direct-style representations, such as ANF. In fact, CPS requires additional transformations and, without special measures, non-distributive flow analysis in CPS is more costly than necessary. Hence, instead of using Kelsey s CPSbased approach, we prefer to formalise the mapping of programs from SSA to ANF (in Section 2); we do so more formally than Appel [2]. Section 3 exploits the correspondence of SSA and ANF by rephrasing Wegman and Zadeck s [22] sparse conditional constants algorithm, which performs constant propagation and unreachable code elimination. In the following, we call Wegman and Zadeck s original SSA-based algorithm Scc ssa and call our new ANF-based algorithm Scc anf. We present Scc anf in a notation that has a well-defined semantics, as opposed to the informal notation used by Wegman and Zadeck. We believe that the semantic rigour of our notation in combination with the well-defined semantics of our intermediate language (namely ANF) implies that Scc anf is significantly better suited to formal analysis. In summary, this paper makes the following technical contributions: We formalise the mapping of programs in SSA form to programs in ANF (Section 2.3). We introduce the algorithm Scc anf, of which we claim that it implements the same analysis on ANF programs as Scc ssa does on SSA programs (Section 3). However, Scc anf is more rigorously defined. We establish that Scc anf is conservative; i.e., that the variables marked as constant are indeed constant (Section 4). However, we do not actually prove that Scc anf and Scc ssa implement the same analysis. In fact, this would be hard to achieve due to Wegman and Zadeck s [22] rather informal presentation. We do, however, present formal statements about the soundness of our mapping of SSA programs to ANF programs and about the soundness of Scc anf. We like to regard the results in this paper as a step towards reaping the well established benefits of typed, functional intermediate languages in compilers for conventional languages. These benefits include simplified reasoning about the correctness of compiler optimisations, type-based validation of optimised code at compile time, and support for the generation of certified binaries [9,20,16,14,18]. Moreover, ANF naturally integrates intra-procedural with inter-procedural analysis. 2

3 2 Making Dataflow Explicit In this section, we define a concrete notation for both SSA and ANF. In addition, we characterise the relationship between these two intermediate forms by a translation procedure that takes programs in SSA form into equivalent programs in ANF. 2.1 Static Single Assignment Form The static single assignment (SSA) form [1] is an imperative representation of programs which encodes data flow information explicitly by requiring that there be exactly one assignment for every variable. Figure 2 presents the factorial function in SSA form. Except for the two φ-functions, the program resembles standard three-address code: fac consists of two basic blocks connected by jumps, with the second (labelled L 1 ) constituting the main loop of the program. For brevity, we allow inlining of blocks in the branches of a conditional statement; in reality, the two assignments in the if statement should be placed in a separate block, so that if indeed represents a conditional jump. The values of the variables x and r are updated in three places in fac. To achieve the single assignment property, we create a new variable for each update, splitting x into x, x 0 and x 1, and similarly for r. Since, the block L 1 can be reached either from the start block or from L 1 itself, at the beginning of L 1 we must merge the two sources of values for x and r using the so-called φ-function, which selects a value based on the source block of the jump. Note that, in SSA, the single-assignment property is purely syntactic, since, in the loop L 1, variables are still updated at runtime on every iteration. A procedure can be put in the SSA form by arranging the basic blocks into a dominator tree, where the parent of each node dominates its children. An assignment dominates an expression if every path to the expression from the start of the procedure includes that assignment. The SSA form has been popularised by Cytron et al. [7], who describe an algorithm for computing the dominance information in linear time and demonstrate how SSA increases the power of many optimisations which require data-flow analysis. Figure 1 presents an abstract syntax of the structured SSA form; i.e., to our variant of SSA in which the dominator tree is explicitely encoded in the block structure. The body of each procedure consists of a sequence of labelled expressions structured into the dominator tree (the first block in each braced group dominates the remaining blocks in that group). Intuitively, the braces provide a traditional scoping hierarchy for block labels. Further, instead of packing variables into a CFG, we follow Kelsey [12] in annotating each parameter to a φ function with the label of the basic block that computes the corresponding value, or start when the value is computed in the unlabelled entry block of the procedure. A complete SSA program p consists of a set of (possibly-recursive) procedures and an entry point e. An SSA expression consists of a sequence of 3

4 p ::= proc x(x) {b} p e b ::= e b; x:e b 1 ; x:{b 2 } e ::= x φ(g); e x v; e x v(v); e goto x; ret v; ret v(v); if v then e 1 else e 2 g ::= l:v l ::= x start v ::= x c x ::= x, x ǫ v ::= v, v ǫ g ::= g, g ǫ x ::= variable or label c ::= constant (SSA) e ::= v v(v) let x = v in e let x = v(v) in e letrec f in e S if v then e 1 else e 2 f ::= x(x) = e v ::= x c x ::= x, x ǫ v ::= v, v ǫ f ::= f; f ǫ x ::= variable c ::= constant (ANF) Fig. 1. Static Single Assignment and A-normal Forms assignments ending with a jump. For the purpose of this discussion, we leave the set of constants unspecified; in general, it will include integers, floating point numbers and machine opcodes (primitives). For simplicity, we assume that all variables and labels in a program are unique. 2.2 Administrative Normal Form The right-hand side of Figure 1 presents an abstract syntax of programs in the administrative normal form (ANF) [8], a direct-style form of lambda terms which, like SSA, restricts function parameters to atomic expressions. As demonstrated by the example ANF code in Figure 2, functions are introduced using letrec expressions, which correspond both to a complete program and the CFG structure of a particular procedure in the SSA form. Tail calls are made explicit by their placement within a let expression: function applications appearing on the right-hand side of a variable binding represent normal calls, while those appearing in the body represent tail calls (jumps). Like the SSA form, ANF encodes data flow explicitly by naming all subexpressions within the program and permitting only a single definition of any particular variable. However, in ANF this restriction is dynamic, since, at runtime, a new scope is created for every invocation of a function. This makes formulation of the ANF semantics straight-forward and intuitive. Further, it reduces the number of mechanisms present for expressing data flow from two (φ-functions and procedures parameters) to one (parameters only), simplifying program analysis and eliminating the artificial distinction between intra- and inter-procedural data flow in SSA. Finally, the syntactically-clear scoping of definitions simplifies formulation of many valid and useful optimisations that involve code motion across basic blocks. In SSA, design of those algorithms is hampered by the need to preserve the dominance property of a program [2]. A formal operational semantics of SSA and ANF programs are presented in the 4

5 proc fac(x) { r 1; goto L 1 ;; L 1 : r 0 φ(start:r, L 1 :r 1 ); x 0 φ(start:x, L 1 :x 1 ); if x 0 then r 1 mul(r 0, x 0 ); x 1 sub(x 0, 1); goto L 1 ; else ret r 0 ;} ret fac(10); (SSA) letrec fac(x) = letrec fac (x 0,r 0 ) = if x 0 then let r 1 = mul(r 0, x 0 ) x 1 = sub(x 0, 1) in fac (x 1, r 1 ) else r 0 in fac (x, 1) in fac(10) (ANF) Fig. 2. SSA and ANF representations of the factorial function unabridged version of this paper [5]. Variants of ANF are used as the intermediate representation in many compilers for functional languages, including GHC [11,21] for Haskell and TIL [20] for ML. 2.3 From SSA to ANF The similarities between the SSA and ANF forms of the factorial function in Figure 2 are immediately obvious: SSA blocks are translated into ANF functions, with the list of arguments derived from the list of φ-expressions in the block. In Figure 3, we define a function F which formalises the translation of a well-formed structured SSA program into ANF. The translation follows the structure of a program in the SSA form. The complete program is translated by F and F p into an all-encompassing outermost letrec. Within each procedure, F b and F l generate an ANF function for every SSA block, with each level of the dominator tree translated into a separate nested letrec. This makes variables defined along the dominator path visible through the usual scoping rules for nested procedures, while constructing a new dynamic scope for each iteration through a translated SSA block. The dominator of a group is selected for the body expression of the letrec. Further, since the leaves of the dominator tree cannot be reached except through their immediate dominator, the scoping rules for ANF enforce the dominance property of the SSA form. If desired, the nested letrec structure in the resulting program can be flattened using the standard lambdalifting [10] transformation. Each SSA block is translated into a separate ANF function. A jump is translated into a tail call to the corresponding function, with the list of parameters obtained by F g from the list of φ-nodes in the destination block. When translating a block into a function, the corresponding list of formal parameters is computed using F φ. Since, in SSA, a variable not defined along the dominator path must be accessed through a φ-node, this enforces the well-formedness of the resulting program. 5

6 The translation function: F( p ) = letrec F p (p) in F e (S p (p),start, ) Collect SSA procedures for the outer letrec: F p ( e ) = ǫ F p ( proc x(x) {b} p ) = x(x)=f b (b,start, B(b, ));F p (p) Construct the inner letrec structure from the dominator tree: F b ( e, l, B) = letrec F l (b, B) in F e (S b (b), l, B) Collect the SSA blocks into an inner letrec list: F l ( e, B) = ǫ F l ( b; x:e, B) = x(f φ (e, ǫ))=f e (e, x, B);F l (b, B) F l ( b 1 ; x:{b 2 }, B) = x(f φ (S b (b 2 ), ǫ))=f b (b 2, x, B(b 2, B));F l (b 1, B) Convert an SSA block to an ANF expression: F e ( x φ(g); e, l, B) = F e (e, l, B) F e ( x v; e, l, B) = let x = v in F e (e, l, B) F e ( x v(v); e, l, B) = let x = v(v) in F e (e, l, B) F e ( ret v;, l, B) = v F e ( ret v(v);, l, B) = v(v) F e ( if v then e 1 else e 2, l, B) = if v then F e (e 1, l, B)else F e (e 2, l, B) F e ( goto x;, l, B) = x(f g (β(b, x), l, ǫ)) Construct a list of function parameters from the φ-nodes: F φ ( x φ(g); e, x) = x,f φ (e, x) F φ ( x v; e, x) = F φ (e, x) F φ ( x v(v); e, x) = F φ (e, x) F φ ( if v then e 1 else e 2, x) = F φ (e 1, F φ (e 2, x)) F φ ( e, x) = x Construct an argument list for a translated jump: F g ( x φ(g); e, l, x) = κ(g, l),f g (e, l, x) F g ( x v; e, l, x) = F g (e, l, x) F g ( x v(v); e, l, x) = F g (e, l, x) F g ( if v then e 1 else e 2, l, x) = F g (e 1, l, F g (e 2, l, x)) F g ( e, l, x) = x Find the entry expression for the program: S p ( e ) = e S p ( proc x(x) {b} p ) = S p (p) Find the entry block for a procedure: S b ( e ) = e S b ( b x:e ) = S b (b) S b ( b 1 ; x:{b 2 } ) = S b (b 1 ) Construct the label list for a procedure: B( e, B) = B B( b; x:e, B) = B(b, B),x e B( b 1 ; x:{b 2 }, B) = B(b 1, B), x S b (b 2 ) Search the list of φ parameters for a label: κ( x 1 :v,g, x 2 ) = if x 1 = x 2 then v else κ(g, x 2 ) Look up a label environment: β( B, x 1 e, x 2 ) = if x 1 = x 2 then e else β(b, x 2 ) Auxiliary syntax for the label environment: B ::= B, x e Fig. 3. Translation of SSA to ANF 6

7 Theorem 2.1 For any well-formed SSA program p, F(p) generates a wellformed ANF program. The proof of Theorem 2.1 relies on well-formedness properies for SSA and ANF, which is presented in the unabridged version of this paper [5]. 3 Sparse Conditional Constants in Functional Form To demonstrate the advantages of ANF over SSA, we introduce an ANF variant of the SSA-based sparse conditional constants algorithm Scc ssa. Due to space constraints, we are not able to present the original algorithm in this paper; please refer to the article of Wegman & Zadeck [22] for a comparison. The reminder of this section defines Scc anf, which we claim discovers the same constants as Scc ssa and removes the same unreachable code, given the ANF term computed from the SSA program using the function F from Figure Prerequisites We assume that the analysed program is in ANF (as defined in Figure 1), that it is first-order, and that all variable names are unique and contained in the set Var. (We discuss higher-order programs in Section 3.5.) Moreover, the set Prim Var contains the names of all primitive functions. The analysis proceeds over an abstract domain Abs = {, } Const, where the c Const are the constant values of the concrete value domain. A partial order is defined on Abs, which has as its least element and as its largest element. 2 More precisely, for each constant c Const, we have c. In addition, we define, for x, y Abs, z = x y to be the least value in Abs such that x z and y z. The intuition underlying this abstract domain is that whenever a variable or function maps to, it never receives a concrete value; 3 whenever it maps to a constant, this is the only value it ever assumes; and whenever it maps to, it is non-constant. We require a function E that implements the evaluation of primitives from Prim; i.e., for p Prim and c i Const, E p(c 1,...,c n ) computes the result of applying p to the c i. Moreover, E Abs extends E to the abstract domain Abs i.e., if any argument to the primitive is or, it yields or, respectively; otherwise, it behaves as E. Apart from the input program, the central data structure of the algorithm is an environment Γ : Var Abs that maps variable names to values of the abstract domain. The environment includes entries for value and function variables, where the latter determine the result value of the function. We write 2 We use the abstract interpretation convention that represents no result and represents conflicting values. This is opposite to the use of the same symbols in the dataflow analysis literature. 3 Note that this includes non-terminating functions; hence, it is not a sufficient condition for concluding that the function is dead code. 7

8 Γx to denote the lookup of the value associated with x in the environment Γ and Γ[x a] to denote updating of the value associated with x to be a. In addition, DomΓ denotes the variables that have an entry in Γ. Finally, we define the refinement of the entry for x by a as Γ [x a] x / DomΓ = Γ[x a] otherwise = Γ[x (Γ x a)] The initial value for the environment is Γ Prim = [p p Prim]. We use FV f to denote all variables that are free in the body of function f; note that this includes all argument variables and, in the case of a recursive function, the function name itself. Conversely, Occ x denotes all functions f, in the program, for which x FV f. The algorithm maintains a work list Ω of names of functions that need to be processed; Ω is initially empty. 3.2 The Algorithm The algorithm computes the optimised form of the program in two phases: The first phase, A, analyses the program by computing the variable environment Γ and the second phase, S, computes the optimised version based on Γ. Both phases are syntax-directed (i.e., proceed according to the ANF grammar from Fig. 1). Note that in the definition of A and S, the meta-variable v may either be a constant c or a value variable x. We assume the canonical extension of Γ to constant values, so that Γc = c. We denote A and S using a notation that can be understood as a L A TEXenhanced version of the purely functional programming language Haskell [15]. Consequently, the semantics of our algorithm is accurately defined by the language definition of Haskell The first phase: program analysis The function A, which is being displayed in Figure 4 (see the next page), gets three arguments: (1) an ANF expression e that is being traversed recursively, (2) the current variable environment Γ, and (3) the current work list Ω. It returns a triple containing (a) the abstract value of e, (b) an updated variable environment, and (c) a new work list. The latter contains functions that are used, but not defined in e, and whose usage has increased the knowledge about the range of argument values with which the functions are invoked. The computationally most costly case of A is that of letrec expressions, where we need to iterate until Γ does not collect any new information. Given a program e in ANF, if A e Γ Prim {} = a, Γ, {}, we can distinguish three cases: If a =, the program does not terminate. If a = c, for a constant c, the program invariably results in c. If a =, the environment Γ characterises the usage of all variables in the 8

9 A v Γ Ω = Γ v, Γ, Ω A f(v 1,...,v n ) Γ Ω f Prim = E Abs f (Γ v 1,..., Γ v n ) otherwise = Γ f, Γ, if changed then Ω {f } else Ω where f is defined as f(x 1,...,x n ) = e Γ = Γ [f, x 1 Γ v 1,..., x n Γ v n ] changed = i. Γ x i Γ v i -- indicates whether Γ changed A let x=e 1 in e 2 Γ Ω = let a, Γ, Ω = A e 1 Γ Ω Γ = Γ [x a] changed = Γ x Γ a affected = Occ x DomΓ -- DomΓ removes not yet used functions in A e 2 Γ (if changed then Ω affected else Ω) A if v then e 1 else e 2 Γ Ω Γ v == =, Γ, Ω Γ v == True = A e 1 Γ Ω Γ v == False = A e 2 Γ Ω Γ v == = let a 1, Γ 1, Ω 1 = A e 1 Γ Ω a 2, Γ 2, Ω 2 = A e 2 Γ 1 Ω 1 in a 1 a 2, Γ 2, Ω 2 A letrec f 1,...,f n in e Γ Ω = let a, Γ, Ω = A e Γ {} Γ, Ω = A fix f 1,..., f n Γ (Ω Ω ) in if Γ == Γ then a, Γ, Ω else A letrec f 1,..., f n in e Γ Ω A fix fun 1,...,fun n Γ Ω i.f i Ω = Γ, Ω otherwise = let a, Γ, Ω = A e Γ {} Γ = Γ [f i a] Ω = Ω Ω \ {f i } in A fix fun 1,..., fun n Γ (if Γ f i Γ a then Ω (Occ f i DomΓ) else Ω ) where (f i (x 1,..., x m )=e) = fun i Fig. 4. The analysis function of Scc anf 9

10 program. In particular, all variables mapping to constant values may be replaced by said constants. Moreover, all functions f / Dom Γ constitute unreachable code. The various equations of A operate as follows. If the analysed expression is simply a constant or variable, we use Γ to determine its abstract value. In the case of the application of a primitive p(v 1,...,v n ), we use Γ to obtain the abstract values of the arguments v i and apply the abstract evaluation function E Abs. More interesting is the case of the application of a user-defined function, f(v 1,...,v n ). The environment Γ is refined to Γ by refining the mapping of each x i (the formal parameters to f) by Γ v i (the concrete values at which f is called). If Γ actually changes during this refinement, f is added to the work list Ω, as we need to (re)process its definition in view of the new environment. The refinement f is important to ensure that f occurs in Γ; i.e., it is flagged as reachable code. If the analysed expression has the form let x=e 1 in e 2, we refine the mapping of x in Γ based on the abstract value of e 1 ; if this refinement changes Γ, all functions that contain x as a free variable are added to the work list, as their abstract value may change as a consequence. Note that we need to intersect Occ x with DomΓ to ensure that only functions that are guaranteed to be reachable are added to the work list. If the analysed expression is a conditionalif v then e 1 else e 2, we form the meet a 1 a 2 of the abstract values of the two branches if the condition variable v is non-constant; otherwise, we choose the branch determined by v. Finally, in the case of an expression letrec f 1,..., f n in e, we first traverse the body expression e, to collect all uses of functions from the mutually recursive set of bindings f 1,...,f n in the modified work list Ω ; afterwards, we analyse the f i using the auxiliary function A fix. The latter is a recursive function that, on each call, picks a function f i that occurs in the current work list and analyses its right hand side. It uses the result to refine the entry of f i in Γ; as in the case of plain let bindings, the work list is extended by Occ f i if Γ changes. The function A fix terminates if none of the f i occur in the work list Ω anymore. This does not mean that Ω is necessarily empty; it may still contain functions defined in enclosing letrec expressions The second phase: program specialisation On the basis of the assignment of abstract values to variables in Γ, the function S transforms the original program into an optimised program that has constant variables and unreachable code removed. The function S operates in a single sweep over the program and exploits the following properties: Whenever Γ maps a variable (function) to a constant c, this variable (function) will contain (return) c in any possible run of the program that uses the variable (invokes the function). Moreover, a value of for a function indicates that it does not terminate. Hence, any occurrence of such a function may be replaced by an arbitrary diverging computation, which we again denote by. 10

11 Any function not in Dom Γ is dead code. The specialisation function that takes the original program in combination with the environment Γ computed by A to the optimised program is defined as follows: S v Γ v / {, } = Γ v -- constant otherwise = v -- non-constant S f(v 1,...,v n ) Γ f = Γ f eval = E f (w 1,..., w n ) otherwise = f (w 1,..., w n ) where w i = S v i, i {1,...,n} eval = f Prim and i {1,...,n}. w i Const S let x=e 1 in e 2 Γ x / {, } = S e 2 -- x is constant otherwise = let x=s e 1 in S e 2 S if v then e 1 else e 2 Γ v == True = S e 1 Γ v == False = S e 2 otherwise = if v then S e 1 else S e 2 S f(x 1,...,x n ) = e f / DomΓ = ǫ -- unused code Γ f = ǫ -- constant function otherwise = f (x 1,..., x n )=S e S letrec f 1,...,f 2 in e = letrec S f 1,..., S f 2 in S e 3.3 Side-Effects So far, we have not discussed how Scc anf treats side-effecting primitives (such as I/O operations). They require some extra care, but do not pose any fundamental problems. Whenever A encounters a side-effecting primitive p (second equation in Figure 4), the result of evaluating the application of p is assumed to be. Moreover, any function whose body contains a side-effecting primitive is mapped to in Γ. The rationale for the latter is that, even if the function is constant, it must not be removed as its invocation carries an effect. Note that the existence of side-effecting primitives is the only reason why we need to be able to distinguish between functions that are dead code and non-terminating functions. If a non-terminating function has an effect, we cannot replace it by an arbitrary diverging computation. In other words, the functions undefined () = undefined () ones () = let x = write char ( 1 ) in ones () need to be treated differently; although, A would assign to both. 11

12 3.4 Inlining As ANF already includes a notion of function abstraction, it lends itself to a uniform representation of a set of functions or procedures, which opens a path to inter-procedural analysis and, in our case, inter-procedural constant propagation. It is well known that combining inlining or procedure integration with constant propagation improves the results. For non-recursive functions (that do not contain side-effecting primitives), this can be easily achieved in Scc anf, by treating them as primitives in A and S. More precisely, in the second equation of the definition of both A and S, we replace the condition f Prim by a more liberal condition of the form f Prim or f is non-recursive. Moreover, we extend E and E Abs by the ability to evaluate non-recursive functions. 3.5 Higher Order Functions Scc anf requires a first-order program, as it does not explicitly handle higherorder variables. Nevertheless, the treatment of higher-order variables is important for modern object-oriented and functional languages. There are various ways of varying sophistication in which Scc anf can be extended to handle higher-order variables. The simplest scheme, giving the least precise results, refines Γ to Γ [x 1,..., x n ] for all functions f(x 1,..., x n ) = e that are assigned to a variable (as opposed to being invoked). This reflects that we cannot gain any knowledge about the range of argument values at which f is invoked. Moreover, A needs to return for any higher-order call site x(x 1,...,x n ), where x is an unknown function value. Although the above mapping of the x i to is correct, it is too conservative as we may be able to statically infer the call sites of some functions that are assigned to variables. In particular, we improve on the basic scheme by using constant propagation to identify higher-order call sites that, for all possible executions of a program, invoke the same function. To do so, it suffices to extend the set of constants contained in the abstract domain Abs with symbols representing the various functions that are used as values. Whenever A derives Γx = f for a call site x(x 1,...,x n ), we can treat this call site as f(x 1,...,x n ). However, by noting the similarity of Scc anf and abstract interpretation [6] as well as the fact that Scc anf corresponds to what is known as a 0CFA analysis [19], we can use power sets of abstract closures as the abstract domain for higher-order variables. A detailed description of the resulting algorithm is beyond the scope of this paper, but it is related to the constant propagation algorithm studied by Sabry and Felleisen [17]. 4 Soundness of the New Algorithm To establish soundness, we need three auxiliary definitions. The first one relates environments w.r.t. the free variables of an expression. It is oblivious 12

13 to the entries relating to bound variables. Definition 4.1 Γ 0 FV(e) Γ 1 x FV e Dom Γ 0, Γ 0 x = Γ 1 x. The next two definitions cover the validity of the algorithm A and its auxiliary function A fix for one particular expression. Definition 4.2 A is valid for an expression e (denoted A e ) iff for any two environments Γ 0 and Γ, with Γ 0 FV(e) Γ, A e Γ 0 {} = a, Γ, Ω implies E Abs e Γ = E Abs S e Γ Γ ; furthermore, if Ω = {}, E Abs e Γ = a. Definition 4.3 A fix is valid for a set of function bindings fs and a work list Ω 0 (denoted A fix fs Ω 0 ) iff for any two environments Γ 0 and Γ, with Γ 0 FV(fs) Γ, we have for every binding f (x 1,..., x n ) = e, A fix fs Γ 0 Ω 0 = Γ, Ω implies E Abs e Γ = E Abs S e Γ Γ whenever f Ω 0. Since the relation FV(e) is oblivious to bound variables, validity implies that the algorithm yields a suitable environment even if bound variables in the input environment differ from the actual value assigned to a variable. This property is important as the algorithm is optimistic i.e., intermediate environments constructed during execution of the algorithm may make incorrect assumptions about the values of some variables. However, the algorithm does not terminate unless all of these bindings are replaced by. Theorem 4.4 (Soundness of A) A is valid for all ANF expressions e. The proof proceeds by induction over the nesting depth of letrecs in an expression and contains the following three main steps: (i) Base Case (A(0)): We assert that for every ANF expression e that contains no letrec expression, we have A e. (ii) Auxiliary Step (A(n) A fix (n)): Given a list of function bindings fs and a work list Ω, we assert that A fix fs Ω holds only if, for all bindings f (x 1,..., x n ) = e from fs, A e holds. (iii) Inductive Step (A(n) A(n + 1)): Given a list of function bindings fs and an ANF expression e, we assert that A e and A fix fs together imply A letrec fs in e. We detail these three steps in the unabridged version of this paper [5]. 5 Conclusion We have formalised the mapping of programs in SSA form to ANF and presented an ANF version of Wegman & Zadeck s conditional constant propagation algorithm, which we called Scc anf. Moreover, we have outlined how the ANF-based algorithm can be extended to include inlining and higher-order functions. We are interested in assessing the usefulness of typed, functional intermediate languages in compilers for conventional languages. The algorithm 13

14 Scc anf is more rigorously defined than Wegman & Zadeck s original algorithm as, firstly, ANF has a well-defined semantics and, secondly, our notation is essentially a nicely typeset version of the programming language Haskell. 4 Such semantic clarity is a prerequisite for any rigorous formal reasoning about compiler optimisations. Moreover, it is a prerequisite for a serious comparison of the work on abstract interpretation with that in the classic dataflow analysis literature. An alternative method for formalising conditional constant propagation in a graph-based framework was introduced by Lerner et al. [13]. However, their focus is on the modular composition of dataflow analyses. Acknowledgements. We thank the referees for their helpful comments. References [1] Alpern, B., M. N. Wegman and F. K. Zadeck, Detecting equality of variables in programs, in: 15th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (1998), pp [2] Appel, A. W., Modern Compiler Implementation in ML, Cambridge University Press, [3] Appel, A. W., SSA is functional programming, ACM SIGPLAN Notices 33 (1998), pp [4] Ballance, R. A., A. B. Maccabe and K. J. Ottenstein, The program dependence web: a representation supporting control-, data-, and demand-driven interpretation of imperative languages, in: Proceedings of the Conference on Programming Language Design and Implementation (1990), pp [5] Chakravarty, M. M. T., G. Keller and P. Zadarnowski, A functional perspective on SSA optimisation algorithms unabridged, Technical Report 0217, University of New South Wales (2003). [6] Cousot, P. and R. Cousot, Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints, in: Proceedings of the 4th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (1977), pp [7] Cytron, R., J. Ferrante, B. K. Rosen, M. N. Wegman and F. K. Zadeck, Efficiently computing static single assignment form and the control dependence graph, ACM Transactions on Programming Languages and Systems 13 (1991), pp [8] Flanagan, C., A. Sabry, B. F. Duba and M. Felleisen, The essence of compiling with continuations, in: Proceedings ACM SIGPLAN 1993 Conf. on Programming Language Design and Implementation, PLDI 93 (1993), pp A concrete implementation of the two functions A and S, in Haskell, is available from 14

15 [9] Harper, R. and G. Morrisett, Compiling polymorphism using intensional type analysis, in: 22nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (1995), pp [10] Johnsson, T., Lambda lifting: Transforming programs to recursive equations, in: Jouannaud, editor, Proceedings of the International Conference on Functional Programming and Computer Architecture, number 201 in Lecture Notes in Computer Science (1985). [11] Jones, S. P. and A. L. M. Santos, A transformation-based optimiser for Haskell, Science of Computer Programming 32 (1998), pp [12] Kelsey, R. A., A correspondence between continuation passing style and static single assignment form, ACM SIGPLAN Notices 30 (1995), pp [13] Lerner, S., D. Grove and C. Chambers, Composing dataflow analyses and transformations, in: Proceedings of the 29th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (2002), pp [14] Morrisett, G., D. Walker, K. Crary and N. Glew, From System F to typed assembly language, ACM Transactions on Programming Languages and Systems 21 (1999), pp [15] Peyton Jones, S. et al., Haskell 98: A non-strict, purely functional language (1999). URL [16] Peyton Jones, S. L., Compiling Haskell by program transformation: a report from the trenches, in: H. R. Nielson, editor, Proceedings of the European Symposium on Programming, Lecture Notes in Computer Science 1058 (1996), pp [17] Sabry, A. and M. Felleisen, Is continuation-passing useful for data flow analysis?, in: Proceedings of the ACM SIGPLAN 94 Conference on Programming Language Design and Implementation (PLDI) (1994), pp [18] Schneider, F. B., G. Morrisett and R. Harper, A language-based approach to security, in: Informatics: 10 Years Back, 10 Years Ahead, Lecture Notes in Computer Science 2000 (2000), pp [19] Shivers, O., Control-flow analysis in Scheme, in: Proceedings of the SIGPLAN 88 Conference on Programming Language Design and Implementation (1988). [20] Tarditi, D., G. Morrisett, P. Cheng, C. Stone, R. Harper and P. Lee, TIL: A type-directed optimizing compiler for ML, in: SIGPLAN Conference on Programming Language Design and Implementation, 1996, pp [21] Tolmach, A. et al., An external representation for the GHC core language (2001). [22] Wegman, M. N. and F. K. Zadeck, Constant propagation with conditional branches, ACM Transactions on Programming Languages and Systems 13 (1991), pp