B. Steffen. Data flow analysis as model checking. In Int. Conf. on Theor. Aspects of Comp. Softw., volume 526 of Lec. Notes in Comp. Sci., pages 346--365. Springer-Verlag, 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... S 0 = S 0 = Sigma meaning that the traditional iterative technique calculates the state sets that satisfy the fixed points. This iterative approach resembles the one taken by iterative data flow analysis [9,23,26] and an overt connection will be made later in the paper [39,41,43,44]. When OE contains alternating fixed points, a tableau method [34,46] can be used to decide specific goals of form, a j= OE. 5.3 Soundness and completeness of universal state checking Because the universal trace abstraction, hff ; fli, is a Galois connection, the standardized soundness ....

B. Steffen. Data flow analysis as model checking. In A. Meyer, editor, Theoretical Aspects of Computer Software: TACS'91, volume 526 of Lecture Notes in Computer Science. Springer-Verlag, 1991.

....programs) have a control flow graph with tree width at most 3 [16] Thus, even for relatively small tree width, our method would cover quite large portion of real programs. 5 Related Work Many researches have been devoted to the declarative approaches to program analyses. Steffen and Schmidt [31, 30] showed that temporal logic is well suited to describe data dependencies and other properties exploited in classical compiler optimization. Lacey, et.al. 21] formalized program optimization as rewriting systems with temporal logic side conditions (described in CTL FV) and shows that CTL FV plays ....

B. Steffen. Data flow analysis as model checking. In Theoretical Aspects of Computer Science, volume 526 of Lecture Notes in Computer Science, pages 346--364. Springer-Verlag, 1991.

....(for papers including broad references to alias analysis see for instance [HBCC99] At the best of our knowledge, we ignore of any previous application of model checker technology to this goal. However, there are various studies about the application of model checking to flow analysis, e.g. [Ste91,DS97]. In these works, it has been shown how many problems usually solved by means of data flow techniques can be solved more simply by model checking techniques. In particular, our work is consistent with the methodology proposed in [SS98] which uses abstract interpretation [CC77] to abstract and ....

B. Steffen, Data Flow Analysis as Model Checking, Proc. Int. Conference on Theoretical Aspects of Computer Software,(TACS 1991), Sendai (Japan), September 1991 , pp. 346-365.

.... In particular model checking can now consider infinite state systems whereas in abstract interpretation it is common to consider properties significantly more complex than safety invariance (see e.g. Dams et al. 1997, Dill and Wong Toi, 1995, Fernandez, 1993, Halbwachs, 1994) and (Steffen, 1991)) We would like to consider further combinations of abstract interpretation and universal safety model checking. 70 COUSOT AND COUSOT Reduction by abstraction consists in approximating infinite or very large finite transition systems by finite ones, on which existing algorithms designed for ....

Steffen, B. 1991. Data flow analysis as model-checking. In T. Ito and A. Meyer Eds., Proc. Int. Conf.

....further the border between classical model checkers and CLPbased systems. Finally, let us point out that several researchers have also addressed a slightly different but very interesting and related issue: the relationship between static analysis (instead of constraint solving) and model checking [6, 45, 48]. ....

B. Steffen. "Data flow analysis as model checking". TACS'91, LNCS 526, SpringerVerlag, 1991.

.... In particular model checking can now consider infinite state systems whereas in abstract interpretation it is common to consider properties significantly more complex than safety invariance (see e.g. Dams et al. 1997, Dill and Wong Toi, 1995, Fernandez, 1993, Halbwachs, 1994) and (Steffen, 1991)) We would like to consider further combinations of abstract interpretation and universal safety model checking. 70 COUSOT AND COUSOT Reduction by abstraction consists in approximating infinite or very large finite transition systems by finite ones, on which existing algorithms designed for ....

Steffen, B. 1991. Data flow analysis as model-checking. In T. Ito and A. Meyer Eds., Proc. Int. Conf.

.... v 2 , where v 1 and v 2 are stores and c is a program statement. Figure 1 gives a concrete interpretation of a one variable program accompanied by an example execution trace of the program with an initial store of 2. We find it convenient and concise to draw an execution trace as a DFA model [17, 18]: Store values label the nodes and the executed statements label the transitions. An abstract interpretation (ai ) is derived from the concrete interpretation by replacing the Store set in the figure by AbsStore, a set of properties that approximate the elements of Store. Figure 2 gives an ....

....graph. This assertion checks whether all paths starting at node s 0 with an even value for x satisfy the stability property the implication s antecedent filters its consequent. In this way, we adapt Steffen s encoding of flow analyses as model checks of cfg s to validate path predicates [17, 18, 19]. As we see in the next section, the translation of an ai into a path predicate encodes a precondition semantics of the ai . Our use of filters as antecedents of implications is reminiscent of the encoding of path fairness predicates into a model check of OE, e.g. is.fair.path oe OE [2, 3] OE ....

B. Steffen. Data flow analysis as model checking. In A. Meyer, editor, Theoretical Aspects of Computer Software: TACS'91, volume 526 of Lecture Notes in Computer Science. SpringerVerlag, 1991.

....feature can be used for the case where the flow graph of a program must be derived during analysis. In addition to analysis specification, Sharlit allows optimization specification, that system Z1 lacks. Young [You89] reported a library that he used to implement several semantic analyses. Steffen [Ste91] reported a specification framework that uses modal logic formulae to specify data flow analysis algorithms. Venkatesh [Ven89] defines a specification language that allows denotational semantics to be augmented with a collecting mechanism for program analysis. None of these tools provides a ....

Bernahard Steffen. Data flow analysis as model checking. In Lecture Notes in Computer Science, volume 526, pages 346--364. 1991.

....data structures in C for the lattice elements and also for flow functions. Thus exchange of implementations is not so easy. SPARE [Ven89] follows the same approach and is additionally tied to the Synthesizer Generator. Generation of data flow analysis from modal logic specification stems from [Ste91]. Although the powerful modal operators allow very short specifications, an application in a real life compiler is not known. All these tools allow for the specification of more complex lattices and flow functions. However, we believe that our method is much more intuitive for the average ....

Bernhard Steffen. Data flow analysis as model checking. In Proceedings of Theoretical Aspects of Computer Software (TACS), pages 346--364, 1991.

....subexpression elimination (CSE) eliminates an expression that is preceded by an identical computation along all incoming paths. Finally, partial redundancy elimination (PRE) subsumes LICM and CSE by eliminating redundancy from instructions that are redundant along only a subset of incoming paths [1, 6, 7, 9, 13, 14, 16, 17, 19]. Since PRE is the most general redundancy elimination, the focus of this paper is on developing an improved PRE algorithm. PRE algorithms avoid repeated computation of the same value by computing the value once, saving it in a temporary, and reusing the value from the temporary when it is needed ....

B. Steffen, "Data Flow Analysis as Model Checking," Proceedings TACS'91, Sendai, Japan, Springer-Verlag, LNCS 526, pages 346-364, 1991.

....4 5 6 7 8 9 10 incr. 1st pass 0.01 0.02 0.05 0.19 0.48 1.36 3.06 7.52 18.90 2nd pass 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 non incr. 0.01 0.02 0.07 0.19 0.47 1.22 3.07 7.50 18.65 Table 1. Execution times, in seconds, for the scheduler example analysis and model checking is investigated in [Ste91] Other directions for future work include the pursuit of incremental algorithms for model checking in the full modal mu calculus [EL86] and for local model checking [SW91] ....

B. Steffen. "Data Flow Analysis as Model Checking". In Proc. TACS'91. LNCS 526, 1991.

....for PRE and PDE optimizations such that code motion is restricted to situations in which the resulting code placement points are those at which the required functional unit resources are available. Moreover we are able to perform code motion more freely than existing PDE and PRE algorithms [16, 17, 21, 5, 15] through speculative hoisting and predication enabled sinking. Finally, path profiling [1] information is used to guide speculation and predication. In particular, speculation and predication is applied only if their overall benefit in form of increased code optimization along frequently executed ....

B. Steffen, "Data Flow Analysis as Model Checking," Proceedings TACS'91, Sendai, Japan, Springer-Verlag, LNCS 526, pages 346-364, 1991.

....by user specified flow path simplification rules. It is unclear, however, how this feature can be used for higher order programs (where functions are normal values) whose control flow is determined while the analysis proceeds. Sharlit does not have a cost accuracy control mechanism. Steffen [50, 51] has reported a data flow analyzer generator based on model checking. The input specification is modal logic formulae that express program properties. The analysis generator evaluates the underlying model checker to generate codes that will iteratively determine the states of the input program ....

....than the iterative fixpoint method. Constraint based approach can also be a convenient vehicle for separate analysis, as reported in [53] Logical approaches to program analysis (like deduction systems for proving properties of programs [7] or model checking from program property specifications [50, 51]) are also alternatives. It would be ideal if Z1 can support all these techniques, so that the user can choose the most suitable method for his analysis problem and for his target language. For some analysis methods (like the constraintsand logic based) however, it seems difficult to provide as ....

Bernhard Steffen. Data flow analysis as model checking. In Lecture Notes in Computer Science, volume 526, pages 346--364. 1991.

....x= p exit exit header (c) Figure 5: Cost Benefit Analysis for Loops. also allows the optimizer to focus on more important expressions while ignoring others and provide new opportunities for code reshaping. 3 Speculative Hoisting Framework A number of solutions to PRE have been proposed [7, 13, 11]. In this section we present an integration of speculation with the expression hoisting framework proposed by Steffen [13] to perform PRE. The modifications to Steffen s framework that are necessary to incorporate speculation are described in this section. Before this modified code motion can be ....

....expressions while ignoring others and provide new opportunities for code reshaping. 3 Speculative Hoisting Framework A number of solutions to PRE have been proposed [7, 13, 11] In this section we present an integration of speculation with the expression hoisting framework proposed by Steffen [13] to perform PRE. The modifications to Steffen s framework that are necessary to incorporate speculation are described in this section. Before this modified code motion can be used we must identify the conditional nodes at which speculation is to be enabled. 3.1 Enabling Speculation To determine ....

B. Steffen, "Data Flow Analysis as Model Checking," Proceedings TACS'91, Sendai, Japan, Springer-Verlag, LNCS 526, pages 346-364, 1991.

No context found.

B. Steffen. Data Flow Analysis as Model Checking. In TACS '91, LNCS 526, pages 346--365. Springer, 1991.

....optimal results, i.e. results where the number of computations on each program path cannot be reduced anymore by means of safe code motion (cf. Theorem 3. 9) Central idea to obtain this optimality result is to place computations as early as possible in a program, while maintaining safety (cf. [Dh2, Dh3, KS2, MR1, St]) However, this strategy moves computations even if it is unnecessary, i.e. there is no run time gain 1 . This causes superfluous register pressure, which is in fact a major problem in practice. In this paper we present a lazy computationally optimal code motion algorithm, which is unique in ....

....as for unidirectional analyses (cf. AU, GW, HU1, HU2, Ke, KU1, Ta1, Ta2, Ta3, Ull] Moreover, our algorithm is conceptually simple. It only requires the sequential computation of the four predicates D Safe, Earliest, Latest, and Isolated. Thus our algorithm is an extension of the algorithm of [St], which simply computes the predicates D Safe and Earliest. The two new predicates Latest and Isolated prevent any unnecessary code motion. 2 Preliminaries We consider variables v 2 V, terms t 2 T, and directed flow graphs G= N; E; s; e) with node set N and edge set E. Nodes n 2 N represent ....

[Article contains additional citation context not shown here]

Steffen, B. Data flow analysis as model checking. In Proceedings TACS'91, Sendai, Japan, Springer-Verlag, LNCS 526 (1991), 346 - 364.

.... solution refine relax specification User Interaction Specification Transformation into Target Language Selected Solution Execution Classification Taxonomy Database Component Repository Retrieval Figure 1: The DaCapo system 2 both finite and infinite state programs (see [Stef91, Stef93, KnRS92, KnRS94a, KnRS94b, Knoo93]) The paper is organized as follows: Section 2 introduces our UNIX application, Section 3 defines the metalevel specification language SLTL, Section 4 illustrates the full DaCapo lifecycle by means of a typical user session, Section 5 discusses the relations with other approaches, and Section 6 ....

B. Steffen. Data flow analysis as model checking. In Proc. TACS '91, volume 526 of Lecture Notes in Computer Science, pp. 346--364, Sendai, Japan, Sept. 1991. Springer--Verlag.

....kinds of model checkers. Intraprocedural dataflow analysis : algorithms of this kind can be realized efficiently and at almost no implementation cost on our analysis machine via a data flow analysis generator which automatically produces fixpoint machine code from high level specifications [Stef91, Stef93, Stef94]. We will discuss this implementation and its performance in Section 6. Regular MC Macro MC CFR PDA MC Equational Systems Solving FIXPOINT ANALYSIS MACHINE Intraprocedural DFA Higher Order DFA Interprocedural DFA Behavioural Relations hardwiring compilation logical characterization [Stef91] ....

....Stef94] We will discuss this implementation and its performance in Section 6. Regular MC Macro MC CFR PDA MC Equational Systems Solving FIXPOINT ANALYSIS MACHINE Intraprocedural DFA Higher Order DFA Interprocedural DFA Behavioural Relations hardwiring compilation logical characterization [Stef91] [Stef93] Stef89] StIn94] Knoo93] Hung94] Ande92] Lars92] BuSt92] BuSt94] Stef93] KnRS94] Fig. 1. Setup of the Analysis Environment Interprocedural data flow analysis : in this setting we are able to cover a wide class of programs that contain recursive procedures with value ....

[Article contains additional citation context not shown here]

B. Steffen: "Data Flow Analysis as Model Checking", Proc. TACS'91, Sendai (Japan), LNCS N. 526, pp. 346-364, Springer V., 1991.

....results, i.e. results where the number of computations on each program path cannot be reduced anymore by means of safe code motion (cf. Theorem 3. 13) The central idea to obtain computational optimality is to place computations as early as possible in a program, while maintaining safety (cf. [6, 8,11,25,27,31]) This strategy, however, moves computations even if it is unnecessary, i.e. there is no runtime gain. 1 In fact, this can cause superfluous register pressure, which is a major problem in practice. In [22] we presented a lazy computationally optimal code motion algorithm, which suppresses any ....

....it is larger for bidirectional problems than for unidirectional ones, and in the worst case it is linear in the size of the flowgraph. 4 A variant of this algorithm which inserts computations on edges rather than in nodes was recently proposed in [13] 5 Such an algorithm was first proposed in [31] which later on was interprocedurally generalized to programs with procedures, local and global variables and formal value parameters in [25] Both algorithms realize an as early as possible placement. it assigns to one of t s operands. 6 Edges (m; n) 2 E represent the nondeterministic ....

Steffen, B. Data flow analysis as model checking. In Proc. TACS (Sendai, Japan, 1991), Lecture Notes in Computer Science 526, Springer-Verlag, pp. 346 -- 364.

....completely unchanged. In contrast, the general treatment of value parameters, which intuitively are much simpler, requires some modification of the whole setting. Fortunately, such modifications are not required for large classes of practically relevant applications [KnRS92, KnRS94, Knoo93] In [Stef91, Stef93], the framework is illustrated by means of an example of practical relevance: an improved version of Morel Renvoise s algorithm for eliminating partial redundancies [MoRe79] The algorithm generated there from a one line specification 3 is as efficient as the standard uni directional algorithms, ....

....kinds of model checkers. ffl Intraprocedural dataflow analysis: algorithms of this kind can be realized efficiently and at almost no implementation cost on our analysis machine via a data flow analysis generator, which automatically produces fixpoint machine code from high level specifications [Stef91, Stef93]. ffl Interprocedural data flow analysis: in this setting we are able to cover a wide class of programs that contain recursive procedures with value parameters. The corresponding data flow analysis generator, which uses the same high level specifications as the intraprocedural version, is under ....

[Article contains additional citation context not shown here]

B. Steffen: "Data Flow Analysis as Model Checking," Proc. TACS'91, Sendai (Japan), LNCS N.526, pp. 346--364, Springer V., 1991.

....results, i.e. results where the number of computations on each program path cannot be reduced anymore by means of safe code motion (cf. Theorem 3. 13) The central idea to obtain computational optimality is to place computations as early as possible in a program, while maintaining safety (cf. [6, 8, 11, 25, 27, 31]) This strategy, however, This research was partly supported by the Deutsche Forschungsgemeinschaft under grants La 426 9 2 and La 426 11 1. Authors current addresses: J. Knoop and O. Ruthing, Institut fur Informatik und Praktische Mathematik, Christian Albrechts Universitat Kiel, ....

....it is larger for bidirectional problems than for unidirectional ones, and in the worst case it is linear in the size of the flowgraph. 4 A variant of this algorithm which inserts computations on edges rather than in nodes was recently proposed in [13] 5 Such an algorithm was first proposed in [31] which later on was interprocedurally generalized to programs with procedures, local and global variables and formal value parameters in [25] Both algorithms realize an as early as possible placement. Optimal Code Motion: Theory Practice ffl 5 the form v : t, where v is a variable and t a ....

Steffen, B. Data flow analysis as model checking. In Proc. TACS (Sendai, Japan, 1991), Lecture Notes in Computer Science 526, Springer-Verlag, pp. 346 -- 364.

....scope of a fixpoint expression. 7 Closed means that all variables are bound by a fixpoint operator, and guarded that they all occur inside the range of a modality. 3. 2 High Level Specifications The recursive proposition constructors add a tremendous amount of expressive power to the logic (cf. [EL, Ste1]) For example, they allow the description of invariance (or safety) and eventuality (or liveness) properties. However, general fixpoint formulas are in general unintuitive and difficult to understand. Therefore, we will consider the intuitively easy to understand derived Henceforth and Weak ....

....for DFA models given in Definition 2.2 can be logically expressed as follows. 7 The point of this condition is to avoid the possibility of alternated nesting [EL] Of course, there are weaker conditions to guarantee this, but they are unnecessarily complicated for our purpose. 8 In [Ste1] more complex operators have been introduced. In this exposition, I will concentrate on a specific format of program models, which can easily be obtained by transformation (see Section 4.1) and simplifies the specification of the data flow analysis algorithms enormously. U F F y y U F y F y ....

[Article contains additional citation context not shown here]

B. Steffen. Data Flow Analysis as Model Checking. In Proceedings TACS'91, LNCS 526, 1991

....optimal results, i.e. results where the number of computations on each program path cannot be reduced anymore by means of safe code motion (cf. Theorem 3. 9) Central idea to obtain this optimality result is to place computations as early as possible in a program, while maintaining safety (cf. [Dh2, Dh3, KS2, MR1, St]) However, this strategy moves computations even if it is unnecessary, i.e. there is no run time gain 2 . This causes superfluous register pressure, which is in fact a major problem in practice. In this paper we present a lazy computationally optimal code motion algorithm, which is unique in ....

....as for uni directional analyses (cf. AU, GW, HU1, HU2, Ke, KU1, Ta1, Ta2, Ta3, Ull] Moreover, our algorithm is conceptually simple. It only requires the sequential computation of the four predicates D Safe, Earliest, Latest, and Isolated. Thus our algorithm is an extension of the algorithm of [St], which simply computes the predicates D Safe and Earliest. The two new predicates Latest and Isolated prevent any unnecessary code motion. 2 Preliminaries We consider variables v 2 V, terms t 2 T, and directed flow graphs G= N; E; s; e) with node set N and edge set E. Nodes n 2 N represent ....

[Article contains additional citation context not shown here]

Steffen, B. Data flow analysis as model checking. In Proceedings TACS'91, Sendai, Japan, Springer-Verlag, LNCS 526 (1991), 346 - 364.

....is no runtime gain, and therefore causes superfluous register pressure, which is a major problem in practice. 1 Recently the problem of unnecessary code motion was addressed in [1] where an algorithm for lazy code motion was presented. In contrast to all previous code motion algorithms (cf. [17, 18, 19, 20, 5, 21]) this algorithm places computations as late as possible in a program, while maintaining computational optimality. 2 It is unique in that it avoids any unnecessary 1 In [16] unnecessary code motion is called redundant. 2 Here, computational optimality means that a program cannot be improved ....

B. Steffen. Data flow analysis as model checking. In Proc. TACS, Lecture Notes in Computer Science 526, pages 346 -- 364, Sendai, Japan, 1991. Springer-Verlag.

No context found.

B. Steffen. Data flow analysis as model checking. In Int. Conf. on Theor. Aspects of Comp. Softw., volume 526 of Lec. Notes in Comp. Sci., pages 346--365. Springer-Verlag, 1991.

No context found.

B. Steffen. Data flow analysis as model checking. In Proceedings of Theoretical Aspects of Computer Science, volume 526 of Lecture Notes in Computer Science, pages 346--364. Springer Verlag, 1991.

No context found.

B. Steffen, "Data Flow Analysis as Model Checking," Proceedings TACS'91, Sendai, Japan, Springer-Verlag, LNCS 526, pages 346-364, 1991.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC