We present a typed intermediate language # CIL for optimizing compilers for function-oriented and polymorphically typed programming languages (e.g., ML). The language # CIL is a typed lambda calculus with product, sum, intersection, and union types as well as function types annotated with flow labels. A novel formulation of intersection and union types supports encoding flow information in the typed program representation. This flow information can direct optimization.

Recent work h& s h wn equivalences between various type systems and flow logics. Ideally, th translations upon wh= h such equivalences are basedshd&@ be faithful in th sense the information is not lost in round-trip translations from flows to types and back or from types to flows and back. Building on t h work of Nielson Nielson and of Palsberg Pavlopoulou, we present t h firstfaithT# translations between a class of finitary polyvariant flow analyses and a type system supporting polymorph@@ in th form of intersection and union types. Additionally, our flow/type correspondence solves several open problems posed by Palsberg Pavlopoulou: (1) it expresses call-string based polyvariance (such as k-CFA) as well as argument based polyvariance; (2) it enjoys a subject reduction property for flows as well as for types; and (3) it supports a flow-oriented perspectiverath# thh a type-oriented one. 1

The CIL compiler for core Standard ML compiles whole programs using a novel typed intermediate language (TIL) with intersection and union types and ow labels on both terms and types. The CIL term representation duplicates portions of the program where intersection types are introduced and union types are eliminated. This duplication makes it easier to represent type information and to introduce customized data representations. However, duplication incurs compiletime space costs that are potentially much greater than are incurred in TILs employing type-level abstraction or quanti cation. In this paper, we present empirical data on the compile-time space costs of using CIL as an intermediate language. The data shows that these costs can be made tractable by using suciently ne-grained ow analyses together with standard hash-consing techniques. The data also suggests that nonduplicating formulations of intersection (and union) types would not achieve signi cantly better space complexity.

The CIL compiler for core Standard ML compiles whole ML programs using a novel typed intermediate language that supports the generation of type-safe customized data representations. In this paper, we present empirical data comparing the relative efficacy of several different flow-based customization strategies for function representations. We develop a cost model to interpret dynamic counts of operations required for each strategy. In this cost model, customizing the representation of closed functions gives a 12–17 % improvement on average over uniform closure representations, depending on the layout of the closure. We also present data on the relative effectiveness of various strategies for reducing representation pollution, i.e., situations where flow constraints require the representation of a value to be less efficient than it would be in ideal circumstances. For the benchmarks tested and the types of representation pollution detected by our compiler, the pollution removal strategies we consider often cost more in overhead than they gain via enabled customizations. Notable exceptions are selective defunctionalization, a function representation strategy that often achieves significant customization benefits via aggressive pollution removal, and a simple form of flow-directed inlining, in which pollution removal allows multiple functions to be inlined at the same call site.

The CIL compiler for core Standard ML compiles whole programs using the CIL typed intermediate language with ow labels and intersection and union types. Flow labels embed flow information in the types and intersection and union types support precise polyvariant type and flow information, without the use of type-level abstraction or quantification. Compile-time representations of CIL types and terms are potentially large compared to those for similar types and terms in systems based on quantified types. The listing-based nature of intersection and union types, together with flow label annotations on types, contribute to the size of CIL types. The CIL term representation duplicates portions of the program where intersection types are introduced and union types are eliminated. This duplication makes it easier to represent type information and to introduce multiple representation conventions, but incurs a compile-time space cost. This paper presents empirical data on the compile-time space cos...

Optimizing compilers for function-oriented and object-oriented languages exploit type and flow information for efficient implementation. Although type and flow information (both control and data flow) are inseparably intertwined, compilers usually compute and represent them separately. Partially, this has been a result of the usual polymorphic type systems using 8 and 9 quantifiers, which are difficult to use in combination with flow annotations. In the Church Project, we are experimenting with intermediate languages that integrate type and flow information into a single flow type framework. This integration facilitates the preservation of flow and type information through program transformations. In this paper we describe CIL, an intermediate language supporting polymorphic types and polyvariant flow information and describe its application in program optimiziation. We are experimenting with this intermediate language in a flow and typedirected compiler for a functional language. ...

This working paper develops a Tofte-Talpin style region inference system... this paper have been formalized in Isabelle and all proofs have been mechanically verified.

The CIL compiler for core Standard ML compiles whole ML programs using a novel typed intermediate language that supports the generation of type-safe customized data representations. In this paper, we present empirical data comparing the relative efficacy of several different customization strategies for function representations. We develop a cost model to interpret dynamic counts of operations required for each strategy. One of our results is data showing that compiling with a function representation strategy that makes customization decisions based on the presence or absence of free variables of a function and which removes representation pollution by introducing multiway dispatch (what we call the selective sink splitting strategy) can produce better code than that produced by a defunctionalizing strategy similar to that in the literature [5, 35, 8].