V. Santhanam and D. Odnert, `Register allocation across procedure and module boundaries', Proceedings of the SIGPLAN 90 Conference on Programming Language Design and Implementation, SIGPLAN Notices, 25, (6), 28--39 (1990).  Home/Search   Document Not in Database   Summary   Related Articles   Check

....paths within each function and try to avoid execution of instructions in the hot paths at the expense of the colder ones. SPIKE applies the Hot Cold Optimization (HCO) 3] on a duplicated copy of the hot path. To accomplish this, they also make use of data and control flow analyses. Others [4, 8, 9, 10, 16] handle the same problem in similar ways using control flow, data flow and call graphs representations of the program, which are needed in order to obtain information about liveness of registers and or variables. For large applications, flow graph representations severely increase the time and ....

V. Santhanam and D. Odnert, "Register Allocation Across Procedure and Module Boundaries", Proceedings of the Conference on Programming Language Design and Implementation, pp. 28-39, June 1990.

....This technique collects information regarding the basic blocks executed, conditional branches taken, functions called etc. at execution time and feeds back to the compiler. Using this information, the compiler can make better decisions regarding the allocation of resources to program variables [Sant90] and aggressiveness with which to apply a particular optimization [McFa91] Optimizations that use profile information are also known as profile based optimizations. While these optimizations do reduce program execution time, they still are not aggressive enough to effectively exploit the cycles ....

Santhanam, V., "Register Allocation Across Procedure and Module Boundaries", Proceedings of SIGPLAN `90 Conference on Programming Language Design and Implementation, White Plains, NY, June 1990, pp. 28-39.

....transform them to a register transfer language (RTL) runs an interprocedural analysis, and performs various interprocedural optimizations, like loop invariant code motion and dead code elimination. It then translates the optimized RTL back to object code. Chow[7] and Odnert and Santhanam [21] both describe systems for the global allocation of registers. These systems do not compile the modules to object code, though. They implement more sophisticated architectures. However, we argue that object code is a too low level program representation for performing cross module optimizations ....

D. Odnert and V. Santhanam. Register allocation across procedure and module boundaries. In Conference on Programming Language Design and Implementation, pages 28-39, June 1990.

....9 Related Work Link time code optimization has been considered by a number of other researchers. Link time register allocation, aimed at allowing global variables to be kept in registers and reducing register saves and restores at inter module calls, is discussed by Santhanam and Odnert [33] and Wall [38] The Zuse Translation System [13] and the mld link time optimizer [19] are aimed at reducing the cost of abstraction in object oriented languages. Ayers et al. describe a production quality link time optimizer for Hewlett Packard systems running HP UX [2] which is distinguished by ....

.... engineered compilers that produce either object files containing special annotations to assist the link time optimizer [38] or an intermediate representation of the program (together with semantic information about it) that is subsequently optimized and translated to executable code by the linker [2, 13, 19, 33]. One implication of this is that performance critical modules written in hand coded assembly language, third party software such as libraries for which source code is 23 not available, or code that is not in the source language supported by the compiler, is not amenable to optimization by these ....

V. Santhanam and D. Odnert, "Register Allocation across Procedure and Module Boundaries", Proc. SIGPLAN '90 Conference on Programming Language Design and Implementation, June 1990, pp. 28--39 26

....of the call graph, register allocation is performed from the leaves to the root over the call graph, like Chow s approach [17] Different registers (not used by the descendants of the current function in the call graph) are assigned to live ranges of the current function. ffl The HP compiler [56] performs inter procedural register allocation using globalvariable promotion and spill code motion. Global variable promotion transforms memory accesses to global variables into register references inside clusters of functions in the call graph. Spill code motion elevates save restore code for ....

V. Santhanam and D. Odnert. Register allocation across procedure and module boundaries. In Proc. SIGPLAN Symp. on Programming Language Design and Implementation, pages 28--39. ACM, June 1990.

.... of researchers: Cooper et al. 13] and Tichy et al. 32] are concerned primarily with low level details of maintaining information to allow a compiler to determine whether a change to one program unit necessitates the recompilation of another, separately compiled, unit, while Santhanam and Odnert [31] consider register allocation across module boundaries. While the motivation for their work is related to ours, the treatment is significantly different in that no attempt is made to give a formal semantic account of the problem or the proposed solutions. In particular, there is no notion of ....

V. Santhanam and D. Odnert. Register allocation across procedure and module boundaries. In Proc. ACM SIGPLAN-90 Conference on Programming Language Design and Implementation, pages 28--39. ACM, 1990.

.... compilers, optimization Additional Keywords and Phrases: inline substitution, interprocedural analysis, interprocedural optimization 1 Introduction In recent years, many articles dealing with issues of interprocedural analysis and interprocedural optimization have appeared in the literature [1, 2, 5, 6, 7, 10, 12, 14, 17, 18, 19, 20, 21]. Several of these articles have attempted to assess the practical value of interprocedural data flow information or of specific cross procedural transformations. Ganapathi and Richardson point out that inline substitution can be viewed as an upper limit on the improvement available through use of ....

V. Santhanam and D. Odnert. Register allocation across procedure and module boundaries. SIGPLAN Notices, 25(6):28--39, June 1990. In Proceedings of the ACM SIGPLAN '90 Conference on Programming Language Design and Implementation.

....interprocedural register allocation and can be seen as a flexible combination of the above; for registers which the code for bar uses, the caller saves convention is used with callee saves used for the rest. Interprocedural register allocation as described here has been used by several authors [30, 12, 4, 28]. This method essentially moves register saving and restoring up in the call graph; this improves the running time of the program if it spends most of its time lower down. If that is not the case, care has to be taken so that the code generated high up in the call graph does not become too ....

....moves register saving and restoring up in the call graph; this improves the running time of the program if it spends most of its time lower down. If that is not the case, care has to be taken so that the code generated high up in the call graph does not become too inefficient. In particular, [28] deals with this problem. When interprocedural register allocation is not used, the registers are often divided statically into caller saves and callee saves registers. This has the benefit that leaf procedures (those that do not call other procedures) can use the caller saves registers as far as ....

V. Santhanam and D. Odnert. Register allocation across procedure and module boundaries. In Proceedings of the ACM SIGPLAN '90 Conference on Programming Language Design and Implementation, volume 25, pages 28--39, White Plains, NY, June 1990. 30

.... hierarchical graph coloring has been proposed by Callahan and Koblenz [6] Although this thesis will focus on intraprocedural allocation, several examples of work in the area of interprocedural or program level global register allocation are work by Chow [7] Wall [8] and Santhanam and Odnert [9]. Chapter 2 describes the register allocation problem and provides a detailed discussion of the graph coloring methods of Chaitin et al. 3] and Chow and Hennessy [4] Chapter 3 presents the implementation details of the IMPACT register allocator. Finally, Chapter 4 contains conclusions and ....

V. Santhanam and D. Odnert, "Register allocation across procedure and module boundaries," in Proceedings of the ACM SIGPLAN 90 Symposium on Programming Language Design and Implementation, pp. 40--52, June 1990. 65

....call would skip the preamble. Wall compares his program wide algorithm to Steenkiste s bottom up approach and concludes that with the use of proling information, his approach performs slightly better, but without it, the bottom up algorithm is slightly better [Wal88] Santhanam and Odnert [SO90] attacks the problem that a global variable in Wall s approach either will be allocated to a register for the complete program or not at all. Their solution is to identify regions of the procedure call graph, called webs, where a global is heavily used (possibly a call intensive region) and ....

V. Santhanam and D. Odnert. Register allocation across procedure and module boundaries. In Proceedings of the ACM SIGPLAN '90 Conference on Programming Language Design and Implementation, volume 25, pages 2839, White Plains, NY, June 1990.

....HCO moves the computation of b to the stub. If p[i] is never true, b is never computed. The first time p[i] is true, we jump to the stub, compute b and then jump into the middle of the loop, so b is never computed again. Much work has gone into profile directed interprocedural register allocation [Wall86, Santhanam90, Kurlander96]. We consider HCO to be a framework for optimization, and a register allocator for this framework is being implemented. Optimizations such as shrink wrapping [Chow88] and ORA [Goodwin96] have sought to reduce unnecessary spills and reloads by placing them in the program where they are executed ....

V. Santhanam and D. Odnert, "Register allocation across procedure and module boundaries" in Proc. ACM SIGPLAN Conf. on Programming Language Design and Implementation `90, White Plains, NY, June 1990

.... of researchers: Cooper et al. 10] and Tichy et al. 24] are concerned primarily with low level details of maintaining information to allow a compiler to determine whether a change to one program unit necessitates the recompilation of another, separatelycompiled, unit, while Santhanam and Odnert [23] consider register allocation across module boundaries. While the motivation for their work is related to ours, the treatment is significantly different in that no attempt is made to give a formal semantic account of the problem or the proposed solutions. These authors have no notion of ....

V. Santhanam and D. Odnert, "Register Allocation across Procedure and Module Boundaries", Proc. ACM SIGPLAN-90 Conference on Programming Language Design and Implementation, White Plains, NY, June 1990, pp. 28--39.

....of the call graph, register allocation is performed from the leaves to the root over the call graph, like Chow s approach [8] Different registers (not used by the descendants of the current function in the call graph) are assigned to live ranges of the current function. ffl The HP compiler [15] performs inter procedural register allocation using global variable promotion and spill code motion. Global variable promotion transforms memory accesses to global variables into register references inside clusters of functions in the call graph. Spill code motion elevates spill code for ....

V. Santhanam and D. Odnert. Register allocation across procedure and module boundaries. In Proc. SIGPLAN Symp. on Programming Language Design and Implementation, pages 28--39. ACM, June 1990.

....automatic and transparent to the user. 1. Introduction Although potential performance improvements from profile based optimizations (PBOs) are well documented [Chang et al. 1991, Chen et al. 1994, Fisher et al. 1984, McFarling and Hennessy 1986, McFarling 1989, Pettis and Hansen 1990, Santhanam and Odnert 1990, Wall 1986] the use of these optimizations has been limited. The key problem with PBOs is the difficulty in obtaining and applying high quality profile data. In current systems, the creation of an optimized executable is typically a multi step process, requiring a programmer to: 1) create a ....

V. Santhanam and D. Odnert. "Register allocation across procedure and module boundaries." Proceedings of the SIGPLAN '90 Conference on Programming Language Design and Implementation, pp. 28-39, 1990.

....high up in the call graph. According to Steenkiste this is normally not a problem since his Lisp programs normally spend most of their time in the bottom of the call graph . Recursion is handled by taking the strongly connected components of the procedure call graph. Santhanam and Odnert [28] develops a two phase compilation method that results in program wide register allocation, trying to allocate global variables better than Wall. They also move spill code out of frequently executed regions. Our approach is similar to Wall s in that it is programwide. However, instead of using a ....

V. Santhanam and D. Odnert. Register allocation across procedure and module boundaries. In Proceedings of the ACM SIGPLAN '90 Conference on Programming Language Design and Implementation, volume 25, pages 28--39, White Plains, NY, June 1990.

.... defined in separately compiled modules, cannot be effectively optimized; this is unfortunate, because one expects programmers to rely more and more on code reuse through libraries as the complexity of software systems grows, there has been some work recently on cross module code optimization [4, 13]: this works for separately compiled user modules but not for libraries) The second problem is that a compiler can only analyze and optimize code written in the language it is designed to compile. Consider an application that investigates the synthesis of chemical compounds using a top level ....

V. Santhanam and D. Odnert, "Register Allocation across Procedure and Module Boundaries", Proc. SIGPLAN '90 Conference on Programming Language Design and Implementation, June 1990, pp. 28--39

.... defined in separately compiled modules, cannot be effectively optimized; this is unfortunate, because one expects programmers to rely more and more on code reuse through libraries as the complexity of software systems grows, there has been some work recently on cross module code optimization [4, 13]: this works for separately compiled user modules but not for libraries) The second problem is that a compiler can only analyze and optimize code written in the language it is designed to compile. Consider an application that investigates the synthesis of chemical compounds using a top level ....

V. Santhanam and D. Odnert, "Register Allocation across Procedure and Module Boundaries", Proc. SIGPLAN '90 Conference on Programming Language Design and Implementation, June 1990, pp. 28--39

....The following subsections describe optimizations that address these problems. 6.1 Register Caching Recall that the target machine registers are implemented by an integer array. Global variables could be used, but most C compilers will not move global variables into real machine registers[18]. Furthermore, this approach is not viable for a multiprocessor implementation. To make effective use of real registers, we cache target machine registers in local C variables for the duration of function calls. We then depend on the C compiler to place the local variables in registers when ....

V. Santhanam and D. Odnert. Register Allocation Across Procedure and Module Boundaries. In Proceedings of the SIGPLAN '90 Conference on Programming Language Design and Implementation, pages 28--39. ACM, June 1990.

.... Such an assessment becomes increasingly important because of the growing number of numerical applications moving from vector supercomputers to scalar processors (on workstations and on multiprocessors) The problem of effectively allocating scalar values in registers has been extensively studied [1, 2, 5, 6, 4, 3, 15, 16, 17]. Typically, a register allocation scheme includes four steps: a live range analysis for different variables; constructing an interference graph; coloring the interference graph with a register spilling scheme; and inserting variable load store and register write back instructions. Current ....

V. Santhanam and D. Odnert. Register allocation across procedure and module boundaries. Proceedings of the ACM SIGPLAN'90 Conference on Programming Language Design and Implementation, White Plains, New York,June 20-22,1990, pp 28-39.

....Programs 7 Related Work Link time code optimization has been considered by a number of other researchers. Link time register allocation, aimed at allowing global variables to be kept in registers and reducing register saves and restores at inter module calls, is discussed by Santhanam and Odnert [30] and Wall [37] The Zuse Translation System [9] and the mld link time optimizer [16] are aimed at reducing the cost of abstraction in object oriented languages. These works rely on specially engineered compilers that produce either object files containing special annotations to assist the ....

.... engineered compilers that produce either object files containing special annotations to assist the link time optimizer [37] or an intermediate representation of the program (together with semantic information about it) that is subsequently optimized and translated to executable code by the linker [9, 16, 30]. One implication of this is that third party software such as libraries for which source code is not available, or code that is not in the source language supported by the compiler, is not amenable to optimization by these tools. Machine level global optimization is discussed also by Johnson and ....

V. Santhanam and D. Odnert, "Register Allocation across Procedure and Module Boundaries", Proc. SIGPLAN '90 Conference on Programming Language Design and Implementation, June 1990, pp. 28--39

.... of researchers: Cooper et al. 10] and Tichy et al. 24] are concerned primarily with low level details of maintaining information to allow a compiler to determine whether a change to one program unit necessitates the recompilation of another, separatelycompiled, unit, while Santhanam and Odnert [23] consider register allocation across module boundaries. While the motivation for their work is related to ours, the treatment is significantly different in that no attempt is made to give a formal semantic account of the problem or the proposed solutions. These authors have no notion of ....

V. Santhanam and D. Odnert, "Register Allocation across Procedure and Module Boundaries", Proc. ACM SIGPLAN-90 Conference on Programming Language Design and Implementation, White Plains, NY, June 1990, pp. 28--39.

No context found.

V. Santhanam and D. Odnert, `Register allocation across procedure and module boundaries', Proceedings of the SIGPLAN 90 Conference on Programming Language Design and Implementation, SIGPLAN Notices, 25, (6), 28--39 (1990).

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