Jens Knoop and Oliver Ruthing. Lazy code motion. In Proc. ACM SIGPLAN 92 Conference on Programming Language Design and Implementation, 92.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... of superblock scheduling [53] a form of trace scheduling [41] Vijaykumar implemented a criticalpath reduction algorithm for the multiscalar processor that moves updates in the control flow graph [120] Steffan et al. have implemented a critical path reduction algorithm based on Lazy Code Motion [63] that moves update instructions to their optimal point [109, 133] As with previous loop distribution algorithms, none of these critical path reduction algorithms can reschedule loops that contain inner loops. Timestamp based algorithms have long been used for concurrency control in transaction ....

Jens Knoop, Oliver Ruthing, and Bernhard Steffen. Lazy code motion. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, 1992.

....For example, after invariant code has been moved out of loops, loop invariant values are easily identified by looking at the location of their definition. We assume that: 1. Lazy code motion (lcm) has been applied to accomplish both loop invariant code motion and common subexpression elimination [33, 35, 23]. Our compiler performs global reassociation and global renaming prior to running lcm [5] 2. Sparse conditional constant propagation (sccp) has been applied to identify and fold compile time constants [47] This discovers a large class of constant values and makes them textually obvious. We ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. SIGPLAN Notices, 27(7):224--234, July 1992. Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation.

....later sections of this paper. A primary objective of scalar optimizations is to minimize the number of computations and the number of references to memory. Scalar optimizations achieve this objective by a natural extension to a well known optimization, called partial redundancy elimination (PRE) [1,2,11], which minimizes the number of times an expression is evaluated. We have extended the PRE of the IA 64 compiler to eliminate both redundant computations and redundant loads of the same or known values. Moreover, the extended PRE uses control and data speculation to increase the number of loads ....

....the loop in Figure 14 has three memory operations per iteration. By using load pair operations, the number of memory references can be reduced to two per iteration. SCALAR OPTIMIZATIONS the number of computations and the number of references to memory. Partial redundancy elimination (PRE) [1, 2, 11] is a well known scalar optimization technique that subsumes global common subexpression elimination (CSE) and loop invariant code motion. CSE removes expressions that are always redundant (redundant on all control flow paths) PRE goes beyond CSE by attempting to remove redundancies that occur ....

J. Knoop, O. Ruthing, and B. Steffen, "Lazy code motion" in Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation, pp. 224-234, June 1992.

....We must be careful not to allow any code that defines memory to move outside of its current loop or to a different loop nesting depth. In addition to the restriction described above, Recall that scheduling follows optimization. The optimization should include some careful code motion [14]. 4 Table 1: Dynamic Instruction Counts for vliw we disallow any operation that defines memory from moving between two blocks if they are in different loops or at different loop nesting levels. In addition, we don t allow an operation that defines anything in liveout(B 1 ) to move between the ....

Jens Knoop, Oliver Ruthing, and Bernhard Steffen. Lazy code motion. SIGPLAN Notices, 27(7):224-- 234, July 1992. Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation.

....transformation must incorporate information about control flow that allowittodistinguish between a partially redundant and afully redundant operation. Two candidates for this redundancy removal phase are traditional common subexpression elimination (cse) 13, 1] or partial redundancy elimination [26, 20]. For this work, we implemented the classic cse framework, reworked to reflect the factthatthe equations are operating on an ssa based name space where kills cannot occur. With information of redundant memory operations, it is now capable to remove the fully static memory redundancy as shown in ....

....store operations, the Muse and M def set size is very small. These measurements explain why the new algorithm runs so quickly. As the data suggest, it has essentially linear time complexity in practice. 6. RELATED WORK Program redundancy detection and removal have long been studied in literature [1, 13, 26, 20, 5]. However, most algorithms only deal with unambiguous scalar values. Aliased memory operations cause the algorithms to use worst case assumptions, i.e. allscalar values related to memory would be killed by an aliased store. On the other hand, work on register promotion focuses solely on memory ....

[Article contains additional citation context not shown here]

Jens Knoop, Oliver Ruthing, and Bernhard Ste#en. Lazy code motion. In Proceedings of the ACM SIGPLAN 1992.

....times slower (including integer overhead) This result is not quite satisfactory, but we believe that the overhead can be considered as a trade o# of e#ciency for security in certain application domains. Moreover, we expect that implementing optimizations such as common subexpression elimination([9], for example) and redundant boundary check elimination in our compiler system will reduce this overhead. Finally, the execution time of poly qsort in Fail Safe C is around 4 8 times as large as the original. This is caused by 1) the additional overhead of runtime type checking, and 2) our ....

Jens Knoop, Oliver Ruthing, and Bernhard Ste#en. Lazy Code Motion. In Proceedings of the 5th ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 224--234, June 1992.

....4 Experimental Results Our research compiler takes C or Fortran code and translates it into our assemblylike intermediate form, iloc [5] The iloc code can then be passed to various op Recall that scheduling follows optimization. The optimization should include some careful code motion [15]. timization passes. All the code for these experiments has been heavily optimized before being passed to the instruction scheduler. These optimizations include pointer analysis for the C codes, constant propagation, global value numbering, dead code elimination, operator strength reduction, lazy ....

Jens Knoop, Oliver Ruthing, and Bernhard Ste#en. Lazy code motion. SIGPLAN Notices, 27(7):224--234, July 1992. Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation.

....locks are acquired for the same object, all but the first could be removed. Similarly, if a read lock request and a write lock request were made on the same object from the same method, the read lock request would be redundant. To address this problem, we could use a variation of lazy code motion [49, 30], a well known compiler optimization. Using this technique, we could eliminate more of the redundant lock acquisitions within a method. Since this method has been shown to be optimal, any redundant lock requests that can be detected will be detected with this method. Lazy code motion also ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation, San Francisco, California, June 1992. 91

....note that the scheduling techniques that we present later in this paper could potentially be applied to the distilled code in the master thread. Our algorithm for reducing the critical forwarding path builds upon previous dataflow approaches to code motion, namely partial redundancy elimination [18], path sensitive dataflow analysis [16] and hot paths [2] Previous work on speculative code motion to exploit a frequently executed path includes trace scheduling [10] and superblock scheduling [5] There has also been work on aggressive load store reordering where the runtime check and recovery ....

.... and end node of G (note that the start node and end node contain no code) Since critical edges (i.e. any edge connecting a node with more than one successor to a node with more than one predecessor) would make our analysis difficult, we break any such edges into two edges using synthetic nodes [18]. At each node n 2 N we define a predicate LocalDef (n) to be the set of communicating scalars that are defined at n. Since the signal instruction that forwards the value of v 2 V must occur after the last definition to v on all possible execution paths, we define No More Definitions at node n ....

KNOOP, J., AND RUTHING, O. Lazy code motion. In Proc. ACM SIGPLAN 92 Conference on Programming Language Design and Implementation (92).

....locks are acquired for the same object, all but the first could be removed. Similarly, if a read lock request and a write lock request were made on the same object from the same method, the read lock request would be redundant. To address this problem, we could use a variation of lazy code motion [21, 13], a well known compiler optimization. Using this technique, we could eliminate more of the redundant lock acquisitions within a method. Since this method has been shown to be optimal, any redundant lock requests that can be detected will be detected with this method. Lazy code motion also ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation, San Francisco, California, June 1992.

....direction of the control ow and placing them in a more general context maximizing in this way the potential of redundant code which can be eliminated thereafter. Under the restriction that no new computations are inserted along any path, computationally optimal results can be obtained statically [25]. However it is assumed that all paths are equally important which is not true in practice. In this section we present a PRE algorithm which takes pro le information into account to reduce the number of recomputations further. By executing expressions speculatively, it enables the removal of ....

J. Knoop, O. Ruthing, and B. Steen, \Lazy Code Motion," ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), pages 224-234, San Francisco, CA, June 1992.

....to array references since they constitute the majority of memory references. Removing redundant loads is therefore a matter of identifying identical array accesses. This is accomplished using SUIF s built in dependence library. For C sources, we use a form of partial redundancy elimination [14] augmented with pointer analysis [23] which allows for the elimination of partially redundant loads. In addition to being a generally useful optimization, redundant load elimination is particularly helpful in SLP analysis. As was discussed in Chapter 4, it reduces the number of packing ....

Jens Knoop, Oliver Ruthing, and Bernhard Steffen. Lazy Code Motion. In Proceedings of the ACM SIGPLAN'92 Conference on Programming Language Design and Implementation, pages 224--234, San Francisco, CA, July 1992.

....for the program analysis component (Section 2.2.2) which traverses all paths between the two assignments. The lexical value representation is used in many basic and advanced optimizations: subexpression elimination, loop invariant code motion [ASU86] and partial redundancy elimination [MR79,Dha91,KRS92] The lexical model is overly restrictive. It fails to uncover value equivalence when two different variables carry the same value. For example, following an assignment x: y, expressions 2 x and 2 y are value equivalent, although lexically different. Value numbering is a method for finding ....

....by code motion obstacles. Such a transformation produces the best static optimization. 2. Hoisted computations are rolled back as low as possible without undoing the optimization. Such a transformation results in the best static optimization with the shortest live ranges of temporaries. In [KRS92,KRS94b] the two phases are called busy code motion and lazy code motion, respectively. The two phase approach complicates the comprehension of the algorithm, for two reasons. First, being an artifact of the dataflow equations, the busy code motion looks different (and hence counter intuitive) ....

[Article contains additional citation context not shown here]

Jens Knoop, Oliver Ruthing, and Bernhard Steffen. Lazy code motion. SIGPLAN Notices, 27(7):224--234, July 1992. Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation.

....(p) y : p) x : a b cmp.unc p,q = a b cmp.unc p,q = a b Figure 4: Benefits for PRE from predication. In this article, we develop a new approach for PRE, which is tailored for predicated code. Conceptually, the basic algorithm we present can be considered the counterpart of busy code motion of [19, 20]. Like busy code motion the new approach relies on two unidirectional data flow analyses. First, a hoistability analysis moving computations to their earliest down safe computation points, i.e. to the earliest points such that the computation will be used on every program continuation reaching ....

....demands on the transformational power. In fact, this ranges from conservative tamed to quite aggressive versions di#erring in the constraints imposed on synthesizing new predicates providing control on the movability of computations. Moreover, extensions in the fashion of lazy code motion (cf. [19, 20]) towards taking the lifetimes of temporaries into account are possible, too. cmp.eq p11,p12 = p11 p12 (p11) cmp p21,p22 = p21) a = x y (p22) x = 1 (p21) b = x y (p22) f = x y (p32) e = x y 2 4 5 6 7 9 10 3 8 11 entry = s p22 p4 = p22 or p31 (p4) h = x y 18 19 20 (p12) c = x y (p12) ....

[Article contains additional citation context not shown here]

J. Knoop, O. Ruthing, and B. Ste#en. Lazy code motion. In Proc. ACM SIGPLAN Conf. on Prog. Lang. Design and Impl. (PLDI'92), volume 27,7 of ACM SIGPLAN Not., pages 224 -- 234, 1992.

.... consequence of the fact that eliminating dead assignment occurrences does not reanimate other dead assignment occurrences, and whose second part is a consequence of the admissibility of g and a simple program transformation supposed in [KRS94b] which is typical for code motion transformations (cf. [DRZ92, KRS92, KRS94a, RWZ88]) namely to insert in every edge leading from a node with more than one successor to a node with more than one predecessor a new synthetic node. Lemma 13. Let G 1 ; G 2 ; G 3 2 G, and g; h 2 T with G 1 h se G 3 . 1. If g 2 E ff , and occ an ff occurrence occurring both in G 1 and G 2 , ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proc. ACM SIGPLAN Conf. on Programming Language Design and Implementation'92, volume 27,7 of ACM SIGPLAN Notices, pages 224 -- 234, San Francisco, CA, June 1992.

No context found.

Jens Knoop and Oliver Ruthing. Lazy code motion. In Proc. ACM SIGPLAN 92 Conference on Programming Language Design and Implementation, 92.

No context found.

Jens Knoop and Oliver Ruthing. Lazy code motion. In Proc. ACM SIGPLAN 92 Conference on Programming Language Design and Implementation, 92.

No context found.

Jens Knoop and Oliver Ruthing. Lazy code motion. In Proc. ACM SIGPLAN 92 Conference on Programming Language Design and Implementation, 92.

No context found.

Jens Knoop, Oliver Ruthing, and Bernhard Steffen. Lazy code motion. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), pages 224--234. ACM Press, 1992.

No context found.

Knoop, J., Rthing, O., Steffen, B. 1992. Lazy Code Motion. In ACM SIGPLAN '92. 224-234.

No context found.

Jens Knoop and Oliver Ruthing. Lazy code motion. In Proc. ACM SIGPLAN 92 Conference on Programming Language Design and Implementation, 92.

No context found.

Jens Knoop, Oliver R uthing, and Bernhard Steffen. Lazy code motion. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), pages 224--234. ACM Press, 1992.

No context found.

J. Knoop, O. Ruthing, and B. Steffen. 1992. "Lazy Code Motion," Proc. ACM SIGPLAN ' 92 Conference on Programming Language Design and Implementation, June, pp. 224-234.

No context found.

Knoop, J., Ruething, O., and Steffen, B. Lazy code motion. In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language 71 Design and Implementation (San Francisco, CA, June 1992), vol. 27, pp. 224-- 234.

No context found.

J. Knoop, O. R uthing, and B. Steffen. Lazy code motion. SIGPLAN Notices, 27(7):224--234, July 1992. Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation.

First 50 documents  Next 50

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