Results 1  10
of
17
Demanddriven Computation of Interprocedural Data Flow
, 1995
"... This paper presents a general framework for deriving demanddriven algorithms for interprocedural data flow analysis of imperative programs. The goal of demanddriven analysis is to reduce the time and/or space overhead of conventional exhaustive analysis by avoiding the collection of information tha ..."
Abstract

Cited by 78 (9 self)
 Add to MetaCart
This paper presents a general framework for deriving demanddriven algorithms for interprocedural data flow analysis of imperative programs. The goal of demanddriven 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 demanddriven 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 nondistributive flow functions the provided dat...
A Practical Framework for DemandDriven Interprocedural Data Flow Analysis
 ACM Transactions on Programming Languages and Systems
, 1998
"... this article, we present a general framework for developing demanddriven 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 demanddriven al ..."
Abstract

Cited by 58 (10 self)
 Add to MetaCart
this article, we present a general framework for developing demanddriven 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 demanddriven 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 twophase framework variation to accurately handle nondistributive problems. A performance evaluation of our demanddriven approach is presented for two data flow problems, namely, reachingdefinitions and copy constant propagation. Our experiments show that demanddriven analysis performs well in practice, reducing both time and space requirements when compared with exhaustive analysis.
A backward analysis for constraint logic programs. Theory and Practice of Logic Programming
"... One recurring problem in program development is that of understanding how to reuse code developed by a third party. In the context of (constraint) logic programming, part of this problem reduces to figuring out how to query a program. If the logic program does not come with any documentation, then ..."
Abstract

Cited by 26 (7 self)
 Add to MetaCart
One recurring problem in program development is that of understanding how to reuse code developed by a third party. In the context of (constraint) logic programming, part of this problem reduces to figuring out how to query a program. If the logic program does not come with any documentation, then the programmer is forced to either experiment with queries in an ad hoc fashion or trace the controlflow of the program (backward) to infer the modes in which a predicate must be called so as to avoid an instantiation error. This paper presents an abstract interpretation scheme that automates the latter technique. The analysis presented in this paper can infer moding properties which if satisfied by the initial query, come with the guarantee that the program and query can never generate any moding or instantiation errors. Other applications of the analysis are discussed. The paper explains how abstract domains with certain computational properties (they condense) can be used to trace controlflow backward (righttoleft) to infer useful properties of initial queries. A correctness argument is presented and an implementation is reported. 1
Between Functions and Relations in Calculating Programs
, 1992
"... 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 ..."
Abstract

Cited by 15 (4 self)
 Add to MetaCart
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...
A DemandDriven Approach for Efficient Interprocedural Data Flow Analysis
 IBM RESEARCH
, 1996
"... ..."
Forward versus Backward Verification of Logic Programs
 Proceedings of Nineteenth International Conference on Logic Programming, volume 2916 of Lecture Notes in Computer Science
, 2003
"... 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 tra ..."
Abstract

Cited by 5 (2 self)
 Add to MetaCart
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 controlflow 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 controlflow 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
Demand Transformation Analysis for Concurrent Constraint Programs
, 1994
"... 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 nonground, downwardsclosed types representing sets of terms in #( ..."
Abstract

Cited by 4 (0 self)
 Add to MetaCart
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 nonground, downwardsclosed 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, "nonvar"), 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...
Goaldirected weakening of abstract interpretation results
, 2006
"... 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 i ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
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 proofconstruction 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 abstractvalue slicers, that slice out unnecessary invariants from the abstract interpretation results. The framework provides interpretation in the whole proofconstruction process, and notifies to the next proofconstruction 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.
Fast Strictness Analysis Based on Demand Propagation
 ACM Transactions on Programming Languages and Systems
, 1995
"... Interpretation versus Demand Propagation Wadler [1987] uses abstract interpretation over a fourpoint 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 lea ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
Interpretation versus Demand Propagation Wadler [1987] uses abstract interpretation over a fourpoint 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 abovementioned 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.
DataFlow Analysis for HotSpot Program Optimization
"... 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 demanddriven dataflow analysis. Particularly suc ..."
Abstract

Cited by 1 (1 self)
 Add to MetaCart
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 demanddriven dataflow analysis. Particularly successful in practice turned out to be an approach based on reverse dataflow 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 dataflow 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 demanddriven dataflow analyses based on reverse dataflow analysis. We illustrate the usability of this approach for hotspot program optimization. It is useful, however, for other applications, too, such as justintime compilation and debugging. 1