This article describes theoretical and practical aspects of an implemented self-applicable partial evaluator for the untyped...

this article, we describe approximation methods for computing interprocedural aliases for a program written in a language that includes pointers, reference parameters, and recursion. We present the following contributions:

Abstract not found

. Data-flow analysis algorithms can be classified into two categories: flow-sensitive and flow-insensitive. To improve efficiency, flowinsensitive interprocedural analyses do not make use of the intraprocedural control flow information associated with individual procedures. Since pointer-induced aliases can change within a procedure, applying known flow-insensitive analyses can result in either incorrect or overly conservative solutions. In this paper, we present a flow-insensitive dataflow analysis algorithm that computes interprocedural pointer-induced aliases. We improve the precision of our analysis by (1) making use of certain types of kill information that can be precomputed efficiently, and (2) computing aliases generated in each procedure instead of holding at the exit of each procedure. We improve the efficiency of our algorithm by introducing a technique called deferred evaluation. Interprocedural analyses, including alias analysis, rely upon the program call graph (PCG) fo...

We describe a system that supports source-level integration of ML-like functional language code with ANSI C or Ada83 code. The system works by translating the functional code into type-correct, "vanilla" C or Ada; it offers simple, efficient, type-safe inter-operation between new functional code components and "legacy" third-generationlanguage components. Our translator represents a novel synthesis of techniques including user-parameterized specification of primitive types and operators; removal of polymorphism by code specialization; removal of higher-order functions using closure datatypes and interpretation; and aggressive optimization of the resulting first-order code, which can be viewed as encoding the result of a closure analysis. Programs remain fully typed at every stage of the translation process, using only simple, standard type systems. Target code runs at speeds comparable to the output of current optimizing ML compilers, even though handicapped by a conservative garbage collector.

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...

This is a follow-on to my 1988 PLDI paper, “Control-Flow Analysis in Scheme”[9]. I usethe methodof abstractsemantic interpretations to explicate the control-flow analysis technique presented in that paper. I begin with a denotational semantics for CPS Scheme. I then present an alternate semantics that precisely expresses the controlflow analysis problem. I abstract this semantics in a natural way, arriving at two different semantic interpretations giving approximate solutions to the flow analysis problem, each computable at compile time. The development of the final abstract semantics provides a clear, formal description of the analysis technique presented in “Control-Flow Analysis in Scheme.” 1

Based on Henglein’s efficient binding-time analysis for the lambda calculus (with constants and “fix”) [Hen91], we develop four efficient analyses for use in the preprocessing phase of Similix, a self-applicable partial evaluator for a higher-order subset of Scheme. The analyses developed in this paper are almost-linear in the size of the analysed program. (1) A flow analysis determines possible value flow between lambda-abstractions and function applications and between constructor applications and selector/predicate applications. The flow analysis is not particularly biased towards partial evaluation; the analysis corresponds to the closure analysis of [Bon91b]. (2) A (monovariant) binding-time analysis distinguishes static from dynamic values; the analysis treats both higher-order functions and partially static data structures. (3) A new is-used analysis, not present in [Bon91b], finds a non-minimal bindingtime annotation which is “safe ” in a certain way: a first-order value may only become static if its result is “needed ” during specialization; this “poor man’s generalization ” [Hol88] increases termination of specialization. (4) Finally, an evaluation-order dependency analysis ensures that the order of side-effects is preserved in the residual program. The four analyses are performed

. Constraint-based analysis is a technique for inferring implementation types. Traditionally it has been described using mathematical formalisms. We explain it in a different and more intuitive way as a flow problem. The intuition is facilitated by a direct correspondence between run-time and analysis-time concepts. Precise analysis of polymorphism is hard; several algorithms have been developed to cope with it. Focusing on parametric polymorphism and using the flow perspective, we analyze and compare these algorithms, for the first time directly characterizing when they succeed and fail. Our study of the algorithms lead us to two conclusions. First, designing an algorithm that is either efficient or precise is easy, but designing an algorithm that is efficient and precise is hard. Second, to achieve efficiency and precision simultaneously, the analysis effort must be actively guided towards the areas of the program with the highest pay-off. We define a general class of algorithms tha...

Safety analysis is an algorithm for determining if a term in an untyped lambda calculus with constants is safe, i.e., if it does not cause an error during evaluation. This ambition is also shared by algorithms for type inference. Safety analysis and type inference are based on rather different perspectives, however. Safety analysis is global in that it can only analyze a complete program. In contrast, type inference is local in that it can analyze pieces of a program in isolation. In this paper we prove that safety analysis is sound , relative to both a strict and a lazy operational semantics. We also prove that safety analysis accepts strictly more safe lambda terms than does type inference for simple types. The latter result demonstrates that global program analyses can be more precise than local ones.