Results 1 - 10
of
45
Typed closure conversion
- In Proceedings of the 23th Symposium on Principles of Programming Languages (POPL
, 1996
"... The views and conclusions contained in this document are those of the authors and should not be interpreted as representing o cial policies, either expressed or implied, of the Advanced Research Projects Agency or the U.S. Government. Any opinions, ndings, and conclusions or recommendations expresse ..."
Abstract
-
Cited by 146 (22 self)
- Add to MetaCart
The views and conclusions contained in this document are those of the authors and should not be interpreted as representing o cial policies, either expressed or implied, of the Advanced Research Projects Agency or the U.S. Government. Any opinions, ndings, and conclusions or recommendations expressed in this material are those of the We study the typing properties of closure conversion for simply-typed and polymorphic-calculi. Unlike most accounts of closure conversion, which only treat the untyped-calculus, we translate well-typed source programs to well-typed target programs. This allows later compiler phases to take advantage of types for representation analysis and tag-free garbage collection, and it facilitates correctness proofs. Our account of closure conversion for the simply-typed language takes advantage of a simple model of objects by mapping closures to existentials. Closure conversion for the polymorphic language requires additional type machinery, namely translucency in the style of Harper and Lillibridge's module calculus, to express the type of a closure.
Compiling with Types
, 1995
"... Compilers for monomorphic languages, such as C and Pascal, take advantage of types to determine data representations, alignment, calling conventions, and register selection. However, these languages lack important features including polymorphism, abstract datatypes, and garbage collection. In contr ..."
Abstract
-
Cited by 97 (14 self)
- Add to MetaCart
Compilers for monomorphic languages, such as C and Pascal, take advantage of types to determine data representations, alignment, calling conventions, and register selection. However, these languages lack important features including polymorphism, abstract datatypes, and garbage collection. In contrast, modern programming languages such as Standard ML (SML), provide all of these features, but existing implementations fail to take full advantage of types. The result is that performance of SML code is quite bad when compared to C. In this thesis, I provide a general framework, called type-directed compilation, that allows compiler writers to take advantage of types at all stages in compilation. In the framework, types are used not only to determine efficient representations and calling conventions, but also to prove the correctness of the compiler. A key property of typedirected compilation is that all but the lowest levels of the compiler use typed intermediate languages. An advantage of this approach is that it provides a means for automatically checking the integrity of the resulting code. An important
A Type System Equivalent to Flow Analysis
- ACM Transactions on Programming Languages and Systems
, 1995
"... Flow-based safety analysis of higher-order languages has been studied by Shivers, and Palsberg and Schwartzbach. Open until now is the problem of finding a type system that accepts exactly the same programs as safety analysis. In this paper we prove that Amadio and Cardelli's type system with subtyp ..."
Abstract
-
Cited by 84 (16 self)
- Add to MetaCart
Flow-based safety analysis of higher-order languages has been studied by Shivers, and Palsberg and Schwartzbach. Open until now is the problem of finding a type system that accepts exactly the same programs as safety analysis. In this paper we prove that Amadio and Cardelli's type system with subtyping and recursive types accepts the same programs as a certain safety analysis. The proof involves mappings from types to flow information and back. As a result, we obtain an inference algorithm for the type system, thereby solving an open problem. 1 Introduction 1.1 Background Many program analyses for higher-order languages are based on flow analysis, also known as closure analysis. Examples include various analyses in the Standard ML of New Jersey compiler [3], and the binding-time analyses for Scheme in the partial evaluators Schism [5] and Similix [4]. Such analyses have the advantage that they can be applied to untyped languages. This is in contrast to more traditional abstract inter...
Infinitary Control Flow Analysis: a Collecting Semantics for Closure Analysis
, 1997
"... Defining the collecting semantics is usually the first crucial step in adapting the general methodology of abstract interpretation to the semantic framework or programming language at hand. In this paper we show how to define a collecting semantics for control flow analysis; due to the generality of ..."
Abstract
-
Cited by 59 (8 self)
- Add to MetaCart
Defining the collecting semantics is usually the first crucial step in adapting the general methodology of abstract interpretation to the semantic framework or programming language at hand. In this paper we show how to define a collecting semantics for control flow analysis; due to the generality of the formulation we need to appeal to coinduction (or greatest fixed points) in order to define the analysis. We then prove the semantic soundness of the collecting semantics and that all totally deterministic instantiations have a least solution; this incorporates k-CFA, polymorphic splitting and a new class of uniform-k-CFA analyses. 1 Introduction Control flow analysis [16, 17] is known by many names: closure analysis [13, 15], set-based analysis [9] (touching upon other constraint-based analyses [1]), and flow analysis [6]. Although the fine formulational details differ they are all variations over a theme, producing analyses of di#erent precision: 0-CFA [16], k-CFA [16, 10], poly-k-CF...
Simple Relational Correctness Proofs for Static Analyses and Program Transformations
, 2004
"... We show how some classical static analyses for imperative programs, and the optimizing transformations which they enable, may be expressed and proved correct using elementary logical and denotational techniques. The key ingredients are an interpretation of program properties as relations, rather tha ..."
Abstract
-
Cited by 57 (9 self)
- Add to MetaCart
We show how some classical static analyses for imperative programs, and the optimizing transformations which they enable, may be expressed and proved correct using elementary logical and denotational techniques. The key ingredients are an interpretation of program properties as relations, rather than predicates, and a realization that although many program analyses are traditionally formulated in very intensional terms, the associated transformations are actually enabled by more liberal extensional properties.
Closure Analysis in Constraint Form
- ACM Transactions on Programming Languages and Systems
, 1995
"... Interpretation Bondorf's definition can be simplified considerably. To see why, consider the second component of CMap(E) \Theta CEnv(E). This component is updated only in Closure Analysis in Constraint Form \Delta 9 b(E 1 @ i E 2 )¯ae and read only in b(x l )¯ae. The key observation is that both ..."
Abstract
-
Cited by 55 (5 self)
- Add to MetaCart
Interpretation Bondorf's definition can be simplified considerably. To see why, consider the second component of CMap(E) \Theta CEnv(E). This component is updated only in Closure Analysis in Constraint Form \Delta 9 b(E 1 @ i E 2 )¯ae and read only in b(x l )¯ae. The key observation is that both these operations can be done on the first component instead. Thus, we can omit the use of CEnv(E). By rewriting Bondorf's definition according to this observation, we arrive at the following definition. As with Bondorf's definition, we assume that all labels are distinct. Definition 2.3.1. We define m : (E : ) ! CMap(E) ! CMap(E) m(x l )¯ = ¯ m( l x:E)¯ = (m(E)¯) t h[[ l ]] 7! flgi m(E 1 @ i E 2 )¯ = (m(E 1 )¯) t (m(E 2 )¯) t F l2¯(var(E1 )) (h[[ l ]] 7! ¯(var(E 2 ))i t h[[@ i ]] 7! ¯(var(body(l)))i) . We can now do closure analysis of E by computing fix(m(E)). A key question is: is the simpler abstract interpretation equivalent to Bondorf's? We might attempt to prove this u...
A practical and flexible flow analysis for higher-order languages
- ACM Transactions on Programming Languages and Systems
, 1996
"... A flow analysis collects data-flow and control-flow information about programs. A compiler can use this information to enable optimizations. The analysis described in this article unifies and extends previous work on flow analyses for higher-order languages supporting assignment and control operator ..."
Abstract
-
Cited by 47 (4 self)
- Add to MetaCart
A flow analysis collects data-flow and control-flow information about programs. A compiler can use this information to enable optimizations. The analysis described in this article unifies and extends previous work on flow analyses for higher-order languages supporting assignment and control operators. The analysis is abstract interpretation based and is parameterized over two polyvariance operators and a projection operator. These operators are used to regulate the speed and accuracy of the analysis. An implementation of the analysis is incorporated into and used in a production Scheme compiler. The analysis can process any legal Scheme program without modification. Others have demonstrated that a 0CFA analysis can enable optimizations, but a 0CFA analysis is O(n3). An O(n) instantiation of our analysis successfully enables the optimization of closure representations and procedure calls. Experiments with the cheaper instantiation show that it is as effective as 0CFA for these optimizations.
From Polyvariant Flow Information to Intersection and Union Types
- J. FUNCT. PROGRAMMING
, 1998
"... Many polyvariant program analyses have been studied in the 1990s, including k-CFA, polymorphic splitting, and the cartesian product algorithm. The idea of polyvariance is to analyze functions more than once and thereby obtain better precision for each call site. In this paper we present an equivalen ..."
Abstract
-
Cited by 39 (7 self)
- Add to MetaCart
Many polyvariant program analyses have been studied in the 1990s, including k-CFA, polymorphic splitting, and the cartesian product algorithm. The idea of polyvariance is to analyze functions more than once and thereby obtain better precision for each call site. In this paper we present an equivalence theorem which relates a co-inductively defined family of polyvariant ow analyses and a standard type system. The proof embodies a way of understanding polyvariant flow information in terms of union and intersection types, and, conversely, a way of understanding union and intersection types in terms of polyvariant flow information. We use the theorem as basis for a new flow-type system in the spirit of the CIL -calculus of Wells, Dimock, Muller, and Turbak, in which types are annotated with flow information. A flow-type system is useful as an interface between a owanalysis algorithm and a program optimizer. Derived systematically via our equivalence theorem, our flow-type system should be a g...

