This paper presents a general framework for deriving demanddriven algorithms for interprocedural data flow analysis of imperative programs. The goal of demand-driven analysis is to reduce the time and/or space overhead of conventional exhaustive analysis by avoiding the collection of information that is not needed. In our framework, a demand for data flow information is modeled as a set of data flow queries. The derived demand-driven algorithms find responses to these queries through a partial reversal of the respective data flow analysis. Depending on whether minimizing time or space is of primary concern, result caching may be incorporated in the derived algorithm. Our framework is applicable to interprocedural data flow problems with a finite domain set. If the problem's flow functions are distributive, the derived demand algorithms provide as precise information as the corresponding exhaustive analysis. For problems with monotone but non-distributive flow functions the provided dat...

this article, we present a general framework for developing demand-driven interprocedural data flow analyzers and report our experience in evaluating the performance of this approach. A demand for data flow information is modeled as a set of queries. The framework includes a generic demand-driven algorithm that determines the response to a query by iteratively applying a system of query propagation rules. The propagation rules yield precise responses for the class of distributive finite data flow problems. We also describe a two-phase framework variation to accurately handle nondistributive problems. A performance evaluation of our demand-driven approach is presented for two data flow problems, namely, reaching-definitions and copy constant propagation. Our experiments show that demand-driven analysis performs well in practice, reducing both time and space requirements when compared with exhaustive analysis.

This thesis is about the calculational approach to programming, in which one derives programs from specifications. One such calculational paradigm is Ruby, the relational calculus developed by Jones and Sheeran for describing and designing circuits. We identify two shortcomings with derivations made using Ruby. The first is that the notion of a program being an implementation of a specification has never been made precise. The second is to do with types. Fundamental to the use of type information in deriving programs is the idea of having types as special kinds of programs. In Ruby, types are partial equivalence relations (pers). Unfortunately, manipulating some formulae involving types has proved difficult within Ruby. In particular, the preconditions of the `induction' laws that are much used within program derivation often work out to be assertions about types; such assertions have typically been verified either by informal arguments or by using predicate calculus, rather than by ap...

Abstract not found

Abstract. One recent development in logic programming has been the application of abstract interpretation to verify the partial correctness of a logic program with respect to a given set of assertions. One approach to verification is to apply forward analysis that starts with an initial goal and traces the execution in the direction of the control-flow to approximate the program state at each program point. This is often enough to verify that the assertions hold. The dual approach is to apply backward analysis to propagate properties of the allowable states against the control-flow to infer queries for which the program will not violate any assertion. This paper is a systematic comparison of these two approaches to verification. The paper reports some equivalence results that relate the relative power of various forward and backward analysis frameworks. 1

Domain In this section we construct a domain of abstract constraints called ACon, which abstracts the domain #(C). In the construction of ACon, we use two domains called D and D V , also introduced in this section, which consist of non-ground, downwards-closed types representing sets of terms in #(H V ) and some basic types, such as the set of integers. (H V is ordered by t 1 t 2 if t 1 is a substitution instance of t 2 .) The domain of types is given by D ::= ? j? j j c(D; : : : ; D) j numj D D j :D. Program variables are not mentioned by types in D. In the syntax of D, c ranges over constructor symbols and is a fixpoint operator. Type variables are given by 2 TV , which are used only for fixpoint constructions. The base types ?, ? (read, "non-var"), and num represent H V , H V n V , and the set of integers, respectively. Example 3.1. fX = ?; Y = ?g is an element of ACon representing the downwardsclosed set of constraints where X is constrained arbitrarily (including not at all...

One proposal for automatic construction of proofs about programs is to combine Hoare logic and abstract interpretation. Constructing proofs is in Hoare logic. Discovering programs’ invariants is done by abstract interpreters. One problem of this approach is that abstract interpreters often compute invariants that are not needed for the proof goal. The reason is that the abstract interpreter does not know what the proof goal is, so it simply tries to find as strong invariants as possible. These unnecessary invariants increase the size of the constructed proofs. Unless the proof-construction phase is notified which invariants are not needed, it blindly proves all the computed invariants. In this paper, we present a framework for designing algorithms, called abstract-value slicers, that slice out unnecessary invariants from the abstract interpretation results. The framework provides interpretation in the whole proof-construction process, and notifies to the next proof-construction phase which invariants it does not have to prove. Using the framework, we designed an abstractvalue slicer for an existing relational analysis and applied it on programs. In this experiment, the slicer identified 62 % − 81 % of the computed invariants as unnecessary, and resulted in 52 % − 84% reduction in the size of constructed proofs.

Interpretation versus Demand Propagation Wadler [1987] uses abstract interpretation over a four-point domain for reasoning about strictness on lists. The four points correspond to undefined list (represented by value 0), infinite lists and lists with some tail undefined (value 1), lists with at least one head undefined (value 2), and all lists (value 3). Burn's work [Burn 1987] on evaluation transformers also uses abstract interpretation on the above-mentioned domain for strictness analysis. He defines four evaluators that correspond to the four points mentioned above in the sense that the ith evaluator will fail to produce an answer when given a list with the abstract value i \Gamma 1.

Abstract. A hot spot of a program is a program region, whose execution time crucially impacts the overall execution time of the program. A hot spot can often be optimized without fully analyzing the whole program. This is supported by approaches for demand-driven data-flow analysis. Particularly successful in practice turned out to be an approach based on reverse data-flow analysis. In this paper, we reconsider this approach. By recalling the Reverse Safety and Coincidence Theorem and the Link Theorem we highlight the duality of classical and reverse data-flow analysis and their relationship to each other. This addresses a common gap in previous presentations of this approach and sheds light on the formal foundation underlying the construction of correct and precise demand-driven data-flow analyses based on reverse data-flow analysis. We illustrate the usability of this approach for hot-spot program optimization. It is useful, however, for other applications, too, such as just-in-time compilation and debugging. 1

This paper presents an approach to static analysis of functional programs that lies between abstract interpretation and flow analysis approaches. Two general frameworks of semantic property analysis for recursion schemes are described. We present a marking technique for solving a rather powerful subset of these problems. Illustrative examples that are captured by this technique are strictness analysis and needed/unneeded analysis. However, some static property analyses of recursive programs described by either flow analysis or abstract interpretation approaches cannot be formulated as either forwards or backwards analysis problems. As an instance, we consider the formal parameter dependence analysis. 1 Introduction To check applicability conditions of equivalent program transformations, to detect semantic errors in programs, and to specialise programs efficiently one should learn how to determine semantic properties of programs. Many 1 authors have explored program analysi...