Iterative fixed point computation for type-based strictness analysis

Abstract

Amtoft has formulated an "on-line" constraint normalization method for solving a strictness inference problem inspired by Wright. From the syntactic form of the normalized constraints he establishes that every program expression has a unique, most precise ("minimal") strictness judgement, given fixed values for the strictness annotation in negative position.We show that his on-line normalization is not required for proving his main syntactic result. Instead of normalizing the constraints during a bottom-up pass through the program we simply collect them first and solve them by standard iterative fixed point methods in a second phase. The main result follows from the fact that observable negative strictness variables only occur on the right-hand sides of the constraints. Furthermore, a standard iterative fixed point algorithm solves the constraints in linear time in the number of strictness variables in the constraint system whereas Amtoft's method requires exponential time.Our presentation is somewhat different than Amtoft's. We use a linearlogic inspired presentation of the programming language and the strictness inference system for it. This results in smaller constraint systems generated. A tight strictness inference normalization result shows that many inequational constraints can be replaced by equational ones. Thus the constraint system can be simplified and significantly reduced in size by efficient variable unification, which can be performed on-line during its construction. Finally, we give an asymptotic worst-case analysis of the size of constraint systems relative to a program with or without explicitly typed variable declarations.The main contributions in this paper are our analysis and method for solving type-based program analyses efficiently, not the design of new type-based program analyses. Generally, our method provides insight into the strengths of noncompositional program analysis algorithms; i.e., algorithms where the solution for a program is not computed as a function of * In Proc. 1st Int'l Static Analysis Symposium (SAS), Namur, Belgium, Sep. 1994, SpringerVerlag Lecture Notes in Computer Science, Vol. 864, pp. 395-407; also available as DIKU Semantics Report D-192 1 the corresponding solutions of its immediate components, such as in Algorithm W or in frontier-based abstract interpretation. 1 In particular, our method demonstrates the effective use of efficient iterative fixed point computation known from classical data flow analysis in type-based program analysis.

Modular, higher order cardinality analysis in theory and practice

“…Running the analyser on nested recursive definitions can be expensive at compiletime. For instance, for two functions f and g, such that g is nested under f, the analyser must find a fixed-point for the inner function g at each iteration of the fixed-point computation for function f. To remedy this, we use the simple widening strategy from the literature (Henglein 1994), based on the observation that iterations of the fixed-point process for f generates a monotonically increasing sequence of usage signatures for f. Therefore, each time we begin the fixed-point process for g, the environment contains values that are no smaller (in the demand partial order) than the corresponding values the previous time we encountered g. It follows that the correct fixed-point for g will be greater than the correct fixed-point found on the previous iteration of f. Therefore, we can begin the fixed-point process for g not with the bottom value, but rather with the result of the previous analysis. In the implementation, this result is conveniently available in the elaborated term e 1 .…”

Annotated Type Systems for Program Analysis

“…One example of this class of annotated type systems is the usage analysis of Wright [Wri91,Amt93a,Amt94,Amt93b,Hen94]. The annotated types and the annotations are:…”