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.

....explanation of the PRE algorithm. We explain how we solve a DFA problem to determine what computations to move and where to compute them. The next section discusses the details of implementation of this DFA problem with Sharlit. We ll omit the proofs because other authors have covered them [20, 65, 55]. Morel and Renvoise, the originators of PRE, defined a DFA problem called anticipated expressions that leads us to the following formulation of code motion. Suppose we have a node v which computes the expression e. Then e is anticipated at a node u, if every execution path that contains u has the ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy Code Motion. In SIGPLAN Conference on Programming Language Design and Implementation, 1992, pp. 224-234.

....since then, but updating sgen to correspond to the latest version of mgen should be straightforward. Peameal, however, does not use the traditional Morel Renvoise formulation of PRE used in oynk. Instead, we use the lazy code motion formulation of PRE proposed by Knoop, Ruthing, and Steffen [1]. Peameal also implements lazy strength reduction , as proposed by the same authors [2] The lazy formulation offers several advantages over the older formulation. It uses only unidirectional data flow problems while the older formulation uses bidirectional problems. This property simplifies ....

Jens Knoop, Oliver Ruthing, and Bernhard Steffen. Lazy Code Motion. In SIGPLAN Conference on Programming Language Design and Implementation, pp. 224-234, 1992.

....reducing the complexity of bidirectional data flow analysis. In this regard, the discovery that bidirectional flows can be converted into approximately equivalent unidirectional flow(s) seems to have been made simultaneously and independently in [13] and [22] Similar approaches were later used in [6, 19 21, 23, 26, 27, 35 39, 47]. The common thread through all these investigations has been performing bidirectional analysis (or its equivalent) using a sequence of unidirectional flows, hence they seem to lead to the impression that : Bidirectional analysis is more complex than unidirectional analysis and since there are ....

....points in the next two sections. This discussion trivially follows from [18, 32, 33] 2.1 Complexity of Bidirectional Data Flow Analysis The misconception about the complexity is an outcome of some initial explorations in bidirectional analysis which were adhoc in nature. These initial forays [13, 19, 20, 35] seem to have received a much wider attention than the Generalized Theory of Bit Vector Data Flow Analysis [18, 32, 33] which has shown that bidirectional data flow problems are inherently no more complex than unidirectional problems, in terms of both conceptual and computational complexity. ....

[Article contains additional citation context not shown here]

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

....can be used to move the wait and signal closer to each other, thereby reducing this critical path. Our compiler schedules these critical paths by first identifying the computation chain leading to each signal, and then using a dataflow analysis which extends the algorithm developed by Knoop [19] to schedule that code in the earliest safe location. We can do even better for any loop induction variable that is a linear function of the loop index; the scheduler hoists the associated code to the top of the epoch and computes that value locally from the loop index, avoiding any extra ....

Jens Knoop and Oliver Ruthing. Lazy code motion. In Proc. ACM SIGPLAN 92 Conferenceon ProgrammingLanguageDesignand Implementation, 92.

....algorithm does not employ demand driven analysis. Our algorithm is also simpler in that it does not require an explicit distinction between speculative and nonspeculative redundancy removal. Finally and most importantly, the focus of their work, like many other works on redundancy elimination [KRS92,BGS98] is on PRE of expressions and not array bounds checks. As we have demonstrated in this paper, elimination of bounds checks has a significantly different character since assertions generated from different sources (loop exit conditions, increments of induction variables, etc. must be ....

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.

....the apparent cost of these unnecessary assignments. Joshi and Dhamdhere [1] proposed incorporating strength reduction into the suppression of partial redundancies. Knoop, Ruthing, and Steffen [3] showed how to implement this in their version of the algorithm (actually, in their earlier variant [2]) including the refinements necessary to combine multiple additions and prevent addition and multiplication from being done on the same path. ....

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, 1992.

....where in the program to insert the computation. These insertions in turn cause partially redundant computations to become fully redundant, and therefore safe to delete. Knoop et al. came up with a different PRE algorithm called lazy code motion that improves on Morel and Renvoise s results [KRS92, DS93, KRS94a] The result of lazy code motion is optimal: the number of computations cannot be further reduced by safe code motion, and the lifetimes of the pseudo registers introduced are minimized. Our team at Silicon Graphics has recently developed a new algorithm to perform PRE based on SSA ....

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

....special cases of partial redundancies, they are subsumed by PRE. As a result, PRE has become the most important component in many global optimizers [Chow 1983; Chow et al. 1986; Schwarz et al. 1988; Briggs and Cooper 1994; Simpson 1996] An alternative placement strategy called lazy code motion [Knoop et al. 1992; Knoop et al. 1994] improves on Morel and Renvoise s results by avoiding unnecessary code movements, and by removing the bidirectional nature of the original PRE data flow equations. The result of lazy code motion is optimal: the number of computations cannot be further reduced by safe code ....

....methods for its solution. Each of the above approaches to PRE is based on a bit vector formulation of the problem, and on the iterative solution of data flow equations. This paper presents a new approach called SSAPRE [Chow et al. 1997] that shares the optimality properties of the best prior work [Knoop et al. 1992; Knoop et al. 1994; Drechsler and Stadel 1993] and that is based on static single assignment form. Static single assignment form (SSA) is a popular program representation in modern optimizing compilers. Its versatility stems from the fact that, in addition to representing the program, it provides ....

[Article contains additional citation context not shown here]

Knoop, J., R uthing, O., and Steffen, B. 1992. Lazy code motion. In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation. 224--234.

....Joshi and Dhamdhere [JD82, Dha89] and Chow [Cho83] independently describe techniques that allow a PRE implementation to simultaneously perform strength reduction. In this framework, strength reduction does not depend on identifying loop induction variables, and is not restricted to loops. In [KRS92, KRS94], Knoop et al. give an alternative PRE algorithm called lazy code motion that improves on Morel 2 and Renvoise s results by avoiding unnecessary code movements, and by removing the bidirectional nature of the original PRE data flow equations. They also presented the lazy strength reduction ....

Knoop, J., Ruthing, O. and Steffen, B., Lazy Code Motion. Proceedings of the SIGPLAN `92 Conference on Programming Language Design and Implementation, June 1992, pp. 224-234.

....algorithm does not employ demand driven analysis. Our algorithm is also simpler in that it does not require an explicit distinction between speculative and nonspeculative redundancy removal. Finally and most importantly, the focus of their work, like many other works on redundancy elimination [KRS92,BGS98] is on PRE of expressions and not array bounds checks. As we have demonstrated in this paper, elimination of bounds checks has a significantly different character since assertions generated from different sources (loop exit conditions, increments of induction variables, etc. must be ....

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.

....the top pointer of the object must be kept in the memory or register. Because CSE generates an interior pointer of an object and the garbage collector does not scan an interior pointer of an object. To reduce accesses to instance variables, the JIT compiler uses partial redundancy elimination [6, 7]. It eliminates redundant accesses in a method by moving invariant accesses out of loops and by eliminating identical accesses that are performed more than once on any execution path. The instance variable moved out of loops can be mapped to a local variable, which can be allocated to a physical ....

Jens Knoop, Ruthing Oliver, and Steffen Bernhard: "Lazy Code Motion," In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation, pp. 224-234, 1992.

....Renvoise [MR79] By targeting partially redundant computations in the program, it automatically removes global common subexpressions and moves invariant computations out of loops. It has since become the most important component in many global optimizers [Cho83, CHKW86, SKL88, BC94, CS95b] In [KRS92, KRS94a] Knoop et al. formulated an alternative placement strategy called lazy code motion that improves on Morel and Renvoise s results by avoiding unnecessary code movements, and by removing the bidirectional nature of the original PRE data flow equations. The result of lazy code motion is ....

....saves of the computation a b into t, giving each t its unique SSA version. Redundant computations of a b are replaced by t. The Phi s for h are translated into OE s for t in the native program representation. 4 SSAPRE Algorithm In this section, we describe the complete SSAPRE algorithm. As in [KRS92] and [DS93] we assume all critical edges in the control flow graph have been removed by inserting empty basic blocks at such edges. This allows us to model insertions as edge placements, even though we only insert at the ends of the predecessor blocks. We assume prior computation of the ....

[Article contains additional citation context not shown here]

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

....illustrated in the example of Section 2. Transformations T1 and T2 might reduce parts of the control ow graph into an MSED node that are not even part of the loop and, therefore, does not need to be split. This problem has not been solved by the above restrictions. Partial redundancy elimination [15] can handle code motion for irreducible regions but will support a weaker form of strength reduction since loop constants cannot be recognized [16] We focus on the recognition and optional transformation of irregular loops that can be utilized for any optimization, such as global register ....

J. Knoop, Oliver Ruthing, and Bernhard Steen. Lazy code motion. In ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 224-233, June 1992.

....opportunities for other optimizations. The new algorithm generalizes earlier work that ordered FORTRAN array address expressions to improve optimization [25] 1 Introduction Partial redundancy elimination is a powerful optimization that has been discussed in the literature for many years (e.g. [21, 8, 14, 12, 18]) Unfortunately, partial redundancy elimination has two serious limitations. It can only recognize lexically identical expressions; this makes effectiveness a function of the choice of names in the front end. It cannot rearrange subexpressions; this makes effectiveness a function of the shape of ....

....The second method, based on available expressions, will handle this case; it removes all redundancies. PRE is stronger yet it removes all redundancies and many partial redundancies as well. 6 Related Work While there have been many papers discussing partial redundancy elimination (e.g. [21, 14, 12, 18]) none mention the deficiencies discussed in Sections 2.2 and 2.3. Rosen et al. recognize the naming problem and propose a complex alternative to PRE; however, they do not consider reordering complex expressions [23] The idea of exploiting associativity and distributivity to rearrange ....

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.

....To specify most DFA problems, one need only to define the three virtual functions described above. However, not all DFA problems are so neatly similar, and some need to specify other parameters. Some problems need more complicated transfer functions; for instance, lazy code motion as described in [17], or bidirectional data flow problems such as the classic partial redundancy algorithm of [25] Other problems need to define the initial value of the In (Out) set of the source (sink) node (e.g. live variables) To satisfy these types of problems, an inheriting class can override the default ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proc. ACM SIGPLAN'92 Conf. on Prog. Language Design and Implementation, pages 224--234. ACM, June 1992.

....(temp) r x 2 r x 3; ld r y 3, temp) The number of overhead operations is counted as 3 (1 load, 1 store, and 1 move) not 2. 4.3.2 Optimization of placement. The insertion of shuffle code is simple and straight forward, but this step may result in partial redundancies in the code. Code hoisting [21], code sinking [22] and partial redundancy [8] techniques can be used to optimize the placement of shuffle loads stores [30] 5. EVALUATION We first compare fusion based register allocation with other approaches, using the framework of Section 3 as a foundation. Then we discuss how a variety of ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proc. ACM SIGPLAN'92 Conf. on Prog. Language Design and Implementation, pages 224--234. ACM, June 1992.

....code in a program. Example applications include common subexpression elimination, loop invariant code motion, and strength reduction. The original PRE framework was developed by Morel and Renvoise [MR79] and has since then experienced various refinements [JD82, DS88, 25 Dha88a, Dha91, DRZ92, KRS92] However, the PRE frameworks developed to date still have certain limitations, which become apparent when trying to apply them to more complex code placement tasks. Atomicity: PRE implicitly assumes that the code fragments it moves, generates, or modifies are atomic in that they need only a ....

....that (n; h) 2 E; i.e. there is only one Cycle edge out of T (h) We will refer to node n as LastChild(h) ffl There are no critical edges, which connect a node with multiple outgoing edges to a node with multiple incoming edges. This can be achieved, for example, by inserting synthetic nodes [KRS92] Code generated for synthetic nodes would reside in newly created basic blocks, for example a new else branch or a landing pad for a jump out of a loop. 41 do i = 1; N y(a(i) if test(i) goto 77 enddo do j = 1; N : enddo 77 do k = 1; N : x(k 10) y(b(k) enddo ....

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

....unnecessary data, but with the potential 5 benefit of additional schedule saving. Another strategy would be to limit communication hoisting to cases where we actually reduce the size or number of messages, which can also be achieved in a straightforward manner similar to lazy code motion [8]; this might decrease the live ranges of our communication buffer with a possible savings in overall buffer storage requirements, but at the expense of reduced opportunities for hiding communication delays. In other words, the definition of HOIST is a matter of heuristics, which is not the case ....

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

.... powerful code motion than [CLZ86, FOW87] eliminates as many redundancies as [AWZ88, RWZ88] except for redundant loops) and provides important information to the code scheduler [BR91] We exhibit a one pass method for elimination of partial redundancies that never performs redundant code motion [KRS92, DS93] and is simpler than the classical [MR79, Dha91] or SSA [RWZ88] methods. These results accrue from eliminating the CFG from the analysis transformation phases and using demand dependences in preference to control dependences. 1 Introduction Program analysis is a prerequisite for important ....

....the demand dependence graph has a small bound. Because our EPR method employs only a partial ordering of the computation as expressed by the dPDG, it is much simpler than methods that employ total orderings expressed as a CFG. For example, as compared to the pure CFG methods [MR79, Dha91, DRZ92, KRS92, DS93] it requires no availability or global (partial) anticipatibility analysis for every expression nor any basic block by basic block code motion. Like more recent CFG based EPR methods, it does not perform re11 dundant code motion. It is also simpler than the SSA method [RWZ88] with its CFG ....

Jens Knoop, Oliver Ruthing, and Bernhard Steffen. Lazy code motion. In Proceedings of the SIGPLAN '92 Conference on Programming Language Design and Implementation, pages 224--234, San Francisco, California, June 17-19, 1992. ACM Press.

....are possible, multiple runs of the algorithm may be necessary in order to get better results. But the profitability terms may prevent optimal results: an assignment which cannot be moved profitably may prevent a profitable motion of another assignment. J. Knoop, O. Ruthing, and B. Steffen [52] present a lazy code motion strategy which places computations as early as necessary but as late as possible. Instead of using bidirectional data flows, it is realized by a sequence of unidirectional equations. Elimination of partially dead as well as partially redundant assignments is discussed ....

....extension of the intraprocedural redundancy elimination approach of Dhamdhere [19] The algorithm is also applicable to recursive procedures. K. Kennedy and A. Sethi [46] propose a constraint based communication placement framework based on the unidirectional PRE algorithm for lazy code motion of [52]. It maximizes latency hiding by determining the earliest safe placement for sends and the latest balanced placement for the corresponding receives. Constrained communication buffer size is used to illustrate constraint analysis and constraint based communication placement. CHAPTER 7. RELATED ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proc. of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation (PLDI'92), pages 224--234, San Francisco,CA, 1992.

....been introduced by Morel and Renvoise [13] for expression optimizations. Dhamdhere et al. 4] improved the Morel Renvoise approach considerably by integrating the concept of edge placement and reducing the resolution costs of bidirectional data flows. Alternatively, Knoop, Ruthing, and Steffen [10] proposed for suppression of partially redundant computations a lazy code motion strategy which is realized by a sequence of unidirectional problems. Moreover, elimination of partially dead assignments has been introduced in [11] in analogy to classical PRE systems. Partial redundancy elimination ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proc. of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation (PLDI'92), pages 224--234, San Francisco,CA, 1992.

....target architectures. Code must be relocated to valid program points and this movement must be safe, in the sense that it must not change what the program flow is intended to compute. The main strategy for code motion is that of moving operations as early as possible in the program as in [9] and [6]. In practice code movement to the earliest program points can create pressure on the target architecture resources e.g. because of register spills . A more practical approach involves also performing temporary lifetime minimization as in the work on Knoop [7] Knoop s approach is the ....

Knoop, J.; Rthing, O.; Steffen, B., "Lazy Code Motion", ACM SIGPLAN, Vo. 27, No. 7, pp. 224-234, 1992.

....(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.

....code size as a third optimization goal to partial redundancy elimination in addition to the two more classical goals of computation costs and register pressure. We arrive at a family of sparse code motion algorithms coming as modular extensions of the algorithms for busy and lazy code motion (cf. [3, 4]) Each algorithm of this family optimally captures a predefined choice of priority between these three optimization goals, e.g. the construction of codesize optimal programs of at least the same e#ciency as the original program, or of computationally optimal programs of minimal code size, each ....

....succ(n) and pred(n) denote the set of all immediate successors and predecessors of a node n. A finite path in G is a sequence #n 1 , n k # of edges such that (n i , n i 1 ) # E for i # 1, k 1 . Every node n # N is assumed to lie on a path from s to e. As in [3] we assume that every edge leading from a branch node to a join node is split by inserting a synthetic node representing the empty statement skip. While splitting these so called critical edges keeps the code motion process simple and more powerful (cf. 3] the following assumption on node ....

[Article contains additional citation context not shown here]

J. Knoop, O. Ruthing, and B. Ste#en. Lazy code motion. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI'92) (San Francisco, California), volume 27,7 of ACM SIGPLAN Notices, pages 224 -- 234, 1992.

.... 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 ....

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proc. PLDI '92, volume 27 of ACM SIGPLAN Notices, pp. 224 -- 234, San Francisco, CA, June 1992.

....: h2 1 2 4 5 6 7 8 9 15 20 16 17 18 19 3 14 15 16 17 18 19 9 4 6 7 5 2 1 10 11 12 13 13 12 11 10 3 ( x,y) x,y) 8 20 14 Figure 2: Back to Reality: Syntactic Code Motion vs. Semantic Code Motion History and Current Situation: Syntactic CM (cf. [2, 6, 7, 8, 9, 10, 11, 14, 15, 18, 19, 21, 25]) is well understood and integrated in many commercial compilers. 3 3 e.g. based on [18, 19] in the Sun SPARCompiler language systems (SPARCompiler is a registered trademark of SPARC International, Inc. and is licensed exclusively to Sun Microsystems, 2 In contrast, the much more powerful and ....

....3 ( x,y) x,y) 8 20 14 Figure 2: Back to Reality: Syntactic Code Motion vs. Semantic Code Motion History and Current Situation: Syntactic CM (cf. 2, 6, 7, 8, 9, 10, 11, 14, 15, 18, 19, 21, 25] is well understood and integrated in many commercial compilers. 3 3 e.g. based on [18, 19] in the Sun SPARCompiler language systems (SPARCompiler is a registered trademark of SPARC International, Inc. and is licensed exclusively to Sun Microsystems, 2 In contrast, the much more powerful and aggressive semantic CM (see Figure 3, which illustrates its power on an irreducible program ....

[Article contains additional citation context not shown here]

J. Knoop, O. Ruthing, and B. Steffen. Lazy code motion. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI'92) (San Francisco, California), volume 27,7 of ACM SIGPLAN Notices, pages 224 -- 234, 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