D. Lacey and O. de Moor. Imperative program transformation by rewriting. In R. Wilhelm, editor, Intl. Conf. on Compiler Construction (CC), volume 2027.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....though they can be used to generate imperative iterative loops from tail recursive programs. Imperative program development is harder than for functional programs because of the possibility of side e ects but the use of temporal logic and control ow graphs has been suggested to overcome this [LdM01] Systems for developing concurrent and distributed programs have also been attempted using temporal logic [OR93] 2.1.2 Proof Driven Transformation It is possible to synthesise programs from a high level speci cation by constructing a proof of the internal consistency of the speci cation in ....

David Lacey and Oege de Moor. Imperative program transformation by rewriting. Lecture Notes in Computer Science, 2027:52-68, 2001.

....of control flow, dependence, aliasing, etc. Thus many tools for imperative languages focus on specifying analyses in addition to transformations; examples include DFAkOPT MetaFrame [23] 23 Sharlit [34] Genesis [39] OPTIMIX [2] Intentional Programming [1] and recent work of Lacey and de Moor [24]. No termination guarantees; no AC rewriting. Our rules are all directed, and we cannot easily express commutative laws without causing endless rewriting. In a modern algebraic transformation system like Maude [9] equations are entirely symmetric in their left and right hand sides, which can be ....

Lacey, D. and O. de Moor, Imperative program transformation by rewriting, in: Proc. Compiler Construction 2001.

....Temporal logic is a logic that is commonly used to express properties of sequences of events. This logic is often used to define properties verifiable using model checking [8] and has been found to be useful for de scribing paths in control flow graphs in order to guide compiler optimizations [10]. Following the latter work, we implement an aspect for Bossa integration as a collection of rewrite rules that use temporal logic to describe conditions under which Bossa event notifica tions should be inserted in kernel code. 3.1 Rewrite rules We propose to define rewrite rules based on ....

....3.3 Describing CFG nodes and paths The conditions in our rewrite rules describe properties of the nodes along a collection of paths in a CFG. For this purpose, we use judgments of the form: n t q where n is a node of the CFG and q is a formula of temporal logic (specifically, a variant of CTL [10]) Formulas in this logic are as follows: p[ m[ 1A2 [ 1V2 I A(i U q2) I S(ql U q2) AA(qi U q) EA(ql U q) I The formula p is any proposition. The operators m, A, and V are defined as in propositional logic. The remaining formulas describe universally and existentially quantified ....

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In R. Wilhelm, editor, Intl. Cony. on Compiler Construction (CC), volume 2027.

....inspected term is needed, term rewriting systems su#ers from this issue. In contrast, graph rewriting provides mechanisms to represent the control flow of a program, the applicability conditions of rewriting are also easier to represent, although the rewriting itself is more di#cult to represent [12]. Providing information to term rewriting by means of dynamic rules and a strategy to emulate the data flow of programs leads to a high level specification for constant propagation which is directly executable. There are many algorithms for constant propagation, most of them use a graph ....

Lacey, D. and O. de Moor, Imperative program transformation by rewriting, in: R. Wilhelm, editor, Proceedings of the 10th International Conference on Compiler Construction, Lecture Notes in Computer Science 2027 (2001), pp. 52--68.

....5 Related Work Many researches have been devoted to the so called declarative approaches to program analyses. Ste#en and Schmidt [34, 33] showed that temporal logic is well suited to describe data dependencies and other properties exploited in classical compiler optimization. Lacey and de Moor [25] added temporal logic side conditions to express complex restriction when transforming imperative programs, and it is shown in [26] that temporal logic plays a crucial role in the proofs of correctness of optimizing transformation. For practical application, an attempt has been made in [13] to ....

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In R. Wilhelm, editor, Proceedings of Compiler Construction 2001. LNCS, Srpinger Verlag, 2001.

....language. Our choice of model checking as an example is not as esoteric as it may appear. Model checking has been used to perform data ow analysis on program control and data ow graphs [Ste93] and to nd optimization and parallelization opportunities in program dependency and ow graphs [RVW98,LdM01] In both cases, temporal logic acts as a speci cation language for certain patterns in a graph representation of the program which are found by a model checker. Thus, temporal logic does have applications in language processing tools and can be seen as a domain speci c speci cation language ....

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In Proc. 10th International Conf. on Compiler Construction, volume 1113 of Lecture Notes in Computer Science, pages 52-68. SpringerVerlag, 2001.

....side conditions. The use of temporal logic plays a central role in the correctness proofs the side condition corresponds in an essential way to a program analysis. Using temporal logic to reason about program transformation is not new, but coupling rewrite rules with temporal logic conditions is [6,7]. So far the only creative part of the correctness proofs has been to nd a suitable invariant between computation pre xes of the subject program and the transformed program. The remainder of the proofs are fairly straight forward and seem well suited for theorem proving. An interesting ....

Lacey, D., and O. de Moor, Imperative Program Transformation by Rewriting, In proc. 10th International Conf. on Compiler Construction, volume 1113 of Lecture Notes in Computer Science, pp 52-68. Springer-Verlag, 2001.

....tree. Consider the examples of position information in parse trees and type annotations in abstract syntax trees to conclude that this is usually not desirable. Finally, full fledged graphs can be useful to represent back links in the tree to represent, for example, loops in a control flow graph [2,33,36], or links to declarations [17] Updateable graphs make it easy to attach new information to nodes, for example results of analysis. The problem of destructive update versus copying while doing transformation is even more problematic in graphs. Since a sub graph can have links to the entire graph, ....

....computing context see [49] Is there a type system that reconciles static typing with generic strategies . How can we transparently deal with variable bindings and other contextsensitive issues What is the interaction between strategies and higher order abstract syntax . In [33] rewrite rules on control flow graphs are defined using temporal logic assertions. What is the role of strategies in graph transformation . Generic strategies parameterized with rules or other strategies often have to renormalize retraverse terms. In [31] an optimization for the case of the ....

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In Compiler Construction (CC'01), Lecture Notes in Computer Science. SpringerVerlag, April 2001.

....] 9 Summary In this paper a framework for describing program transformations as conditional rewrite rules has been presented. Specifying program transformations as rewrite rules with temporal logic side conditions is a relatively new approach to proving correctness of program transformations [5, 4]. The main focus in this paper has been on the correctness of program transformations rather than orthogonal issues. In order to apply a transformation in the present framework, the overall transformation strategy must decide on a particular program point, before the side condition is veri ed. ....

David Lacey and Oege de Moor. Imperative Program Transformation by Rewriting. Compiler Construction (CC2001.

....[18] A programming language is low level when its programs require attention to the irrelevant. Alan Perlis But how should we decide what is relevant Within the functional programming community, there is a strong historical connection between functional programming and formal modeling [1,24,25,12]. Many authors have expressed the view that functional programming languages are high level because they allow programs to be written in terms of an abstract conceptual model of the problem domain, without undue concern for implementation details. Of course, although functional languages can be ....

....J. Theories of Programming Languages, Cambridge University Press, 1998. 23] Sage, M. Frantk: A declarative gui system for haskell, in: Proceedings of the ACM SIGPLAN International Conference on Functional Programming (ICFP 2000) 2000. URL http: www.haskell.org FranTk userman.pdf [24] Stoy, J. E. Some mathematical aspects of functional programming, in: J. Darlington, P. Henderson and D. A. Turner, editors, Functional Programming and its Applications, Cambridge University Press, 1982 pp. 217 252. 25] Turner, D. A. Functional programs as executable specifications, ....

[Article contains additional citation context not shown here]

Lacey, D. and O. de Moor, Imperative program transformation by rewriting, in: Proc. Compiler Construction

....etc. Thus many tools for imperative languages focus on specifying analyses in addition to transformations; examples include DFA OPT MetaFrame [23] 23 Peyton Jones, Tolmach, and Hoare Sharlit [34] Genesis [39] OPTIMIX [2] Intentional Programming [1] and recent work of Lacey and de Moor [24]. No termination guarantees; no AC rewriting. Our rules are all directed, and we cannot easily express commutative laws without causing endless rewriting. In a modern algebraic transformation system like Maude [9] equations are entirely symmetric in their left and right hand sides, which can be ....

Lacey, D. and O. de Moor, Imperative program transformation by rewriting, in: Proc. Compiler Construction

....tree. Consider the examples of position information in parse trees and type annotations in abstract syntax trees to conclude that this is usually not desirable. Finally, full edged graphs can be useful to represent back links in the tree to represent, for example, loops in a control ow graph [2, 32, 34], or links to declarations [16] Updateable graphs make it easy to attach new information to nodes, for example results of analysis. The problem of destructive update versus copying while doing transformation is even more problematic in graphs. Since a sub graph can have links to the entire graph, ....

.... context see [46] Types Is there a type system that reconciles static typing with generic strategies Variables How can we transparently deal with variable bindings and other context sensitive issues What is the interaction between strategies and higher order abstract syntax Graphs In [32] rewrite rules on control ow graphs are de ned using temporal logic assertions. What is the role of strategies in graph transformation Fusion Generic strategies parameterized with rules or other strategies often have to renormalize retraverse terms. In [30] an optimization for the case of the ....

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In Compiler Construction (CC'01), Lecture Notes in Computer Science. SpringerVerlag, April 2001.

No context found.

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In R. Wilhelm, editor, Compiler Construction, 52--68. Springer Verlag, 2001.

....it places on the expressiveness of path queries. 17 4 Discussion This paper is part of a larger e ort to construct a toolkit for easy experimentation with compiler optimisations. In previous work, we have speci ed the side conditions of such transformations in a variant of temporal logic [41], inspired by the work of Ste en and his coworkers on specifying data ow analyses through temporal logic [59] The formulae in temporal logic are veri ed using a model checker, which also nds instantiations of free variables. We noticed that many of our examples do not use the full power of ....

D Lacey and O de Moor. Imperative program transformation by rewriting. In R Wilhelm, editor, Compiler Construction, volume 2027.

....constant propagation. The idea to use such speci cations for program analysis is due to Bernhard Ste en and his co workers [38] Following the lead of Van Wyk and Rus [32] in our rst attempt to apply their ideas to the speci cation of transformations we employed a variant of modal logic [22]. Later we explored regular expressions as an alternative, somewhat simpler notation for the same ideas [11] a derivation of the same solving algorithm, with more emphasis on the necessary data structures, but restricted to ground queries, can be found in [28] Due to space limitations, we shall ....

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In R. Wilhelm, editor, Proceedings of the 10th International Conference on Compiler Construction, volume 2027.

....enabling new and stronger code motion algorithms, now part of several commercial compilers. More relevant to this paper: The code motion transformations could be proven correct. 1. 5 Model checking and program transformation In this paper we give a formalism (essentially it is a subset of [18]) for succinctly expressing program transformations, making use of temporal logic; and use this formalism to prove the universal correctness (semantics preservation for all programs) of the three optimizing transformations: dead code elimination, constant folding and loop invariant hoisting. The ....

....paper s approach may be found in [7] Many optimizing transformations can be elegantly expressed using rewrite rules of form: I =# I # if #, where I, I # are intermediate language instructions and # is a property expressed in a temporal logic suitable for describing program data flow. Its reading [18]: If the current program # contains an instruction of form I at some control point p, and if flow condition # is satisfied at p, then replace I by I # . The purpose of this paper is to show how such transformations may be proven correct. The meaning of correctness is that for any program #, if ....

[Article contains additional citation context not shown here]

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In Proc. 10th International Conf. on Compiler Construction, volume 1113 of Lecture Notes in Computer Science, pages 52--68. Springer-Verlag, 2001.

....all such elements, apply ps 0 , and then take the union. 5 Discussion This paper is part of a larger e ort to construct a toolkit for easy experimentation with compiler optimisations. In previous work, we have speci ed the side conditions of such transformations in a variant of temporal logic [42], inspired by the work of Ste en and his coworkers on specifying data ow analyses through temporal logic [58] The formulae in temporal logic are veri ed using a model checker, which also nds instantiations of free variables. We noticed that many of our examples do not use the full power of ....

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In Proceedings Programming Language Implementation and Logic Programming (PLILP), and Algebraic and Logic Programming (ALP), volume 844 of Lecture Notes in Computer Science, pages 5-24. Springer, 1994.

....temporal logic, enabling new and stronger code motion algorithms, now part of several commercial compilers. More relevant to this paper: The code motion transformations could be proven correct. 1. 4 Model checking and program transformation In this paper we give a formalism (essentially that of [13]) for succinctly expressing program transformations, making use of temporal logic; and use this formalism to prove the universal correctness (semantics preservation for all programs) of the three optimizing transformations: dead code elimination, constant folding and loop invariant hoisting. The ....

....optimizations can be validated. Many optimizing transformations can be elegantly expressed using rewrite rules of form: I = I 0 if , where I; I 0 are intermediate language instructions and is a property expressed in a temporal logic suitable for describing program data ow. Its reading [13]: If the current program contains an instruction of form I at some control point p, and if ow condition is satis ed at p, then replace I by I 0 . The purpose of this paper is to show how such transformations may be proven correct. The meaning of correctness is that for any program , if ....

[Article contains additional citation context not shown here]

D. Lacey and O. de Moor. Imperative Program Transformation by Rewriting. Compiler Construction, 2001.

....n = # A # (# 1 U # 2 ) is similar except that is says that all backward paths satisfy # 1 up to a point that satisfies # 2 . Finally, modal formulae can be combined in the standard way by the logical connectives #,# and . The rewrite language presented here is a simplification of that in [5]. The reasons for the simplification and discussion of possible extensions can be found in Section 8. It is important to note that these are executable specifications, an algorithm exists that takes these specifications and a program as input and applies the transformations to the program. In some ....

D Lacey and O de Moor. Imperative program transformation by rewriting. In R Wilhelm, editor, Compiler Construction, volume

....all such elements, apply ps 0 , and then take the union. 5 Discussion This paper is part of a larger e ort to construct a toolkit for easy experimentation with compiler optimisations. In previous work, we have speci ed the side conditions of such transformations in a variant of temporal logic [42], inspired by the work of Ste en and his coworkers on specifying data ow analyses through temporal logic [58] The formulae in temporal logic are veri ed using a model checker, which also nds instantiations of free variables. We noticed that many of our examples do not use the full power of ....

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In Proceedings Programming Language Implementation and Logic Programming (PLILP), and Algebraic and Logic Programming (ALP), volume 844 of Lecture Notes in Computer Science, pages 5-24. Springer, 1994.

No context found.

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In R. Wilhelm, editor, Intl. Conf. on Compiler Construction (CC), volume 2027.

No context found.

D. Lacey and O. de Moor. Imperative program transformation by rewriting. In Compiler Construction (CC'01), Lecture Notes in Computer Science. Springer-Verlag, April 2001.

No context found.

David Lacey and Oege de Moor. Imperative program transformation by rewriting. Lecture Notes in Computer Science, 2027:52--68, 2001. URL citeseer.nj.nec.com/ lacey01imperative.html.

No context found.

David Lacey and Oege de Moor. Imperative program transformation by rewriting. Lecture Notes in Computer Science, 2027:52--67, 2001.

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