Urban Boquist. Interprocedural register allocation for lazy functional languages. In Proceedings of the 1995 Conference on Functional Programming Languages and Computer Architecture. ACM Press, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....on. More importantly, regardless of separate compilation, at runtime, we have access to all interfaces and in principle to arbitrary inter module information; this is especially signicant for functional languages, where module boundaries hinder all sorts of analysis and optimisations (e.g. HPS94,Boq95,BJ97] Finally, there is no need to specialise the whole program in one go at load time; instead, initial specialisation as well as rening optimisations can be applied successively as need arises during the execution, and thus, code generation can exploit proling information to concentrate on ....

Urban Boquist. Interprocedural register allocation for lazy functional languages. In Proceedings of the 1995 Conference on Functional Programming Languages and Computer Architecture. ACM Press, 1995.

....or binding time analysis for partial evaluation. Sestoft, in [18] however, explores the use of closure information to turn first order analyses into higher order analyses which is close in spirit to our applications were we combine flow information with local information. Recently, Boquist [3] has applied a constructor analysis due to Johnsson to the optimization of a graph reduction intermediate language. The transformations performed are related to our eval elimination, but the formulation is rather different. Boquist also uses the analysis information to enable interprocedural ....

Urban Boquist. Interprocedural register allocation for lazy functional languages. In FPCA'95, 1995.

....on a per procedure basis and reduce the call and return overheads by propagating and using some program wide procedure function call information. The approach to perform program wide register allocation on all variables in the program at once have been taken by Wall [Wal86] and by Boquist [Boq95] Wall postpones most of the actual register allocation to link time and confines to a limited form of local allocation at compile time. The code produced include annotations on which loads and stores to remove if a particular variable is assigned a register in the link time allocation. Walls ....

....variables in the 3 address code setting. To our knowledge, we are the first to develop a type system capable of checking the correctness of register assignments made to lambda calculus terms. The approach to unknown functions we have taken can be seen as the converse of that of Boquist [Boq95, BJ96] Our constrained types place restrictions on the register behaviour of function arguments when they are passed and thus the caller is forced to see to it that the functions arguments it passes meet these restrictions requirements. Boquist, on the other hand, performs a data flow analysis ....

Urban Boquist. Interprocedural Register Allocation for Lazy Functional Languages. Licentiate Thesis, Chalmers University of Technology, Mars 1995. URL: http://www.cs.chalmers.se/~boquist/lic.ps.

....known functions. Not only does it eliminate the call overhead of EVAL, it also increases the sise of the code portions voer which variables might usefully reside in registers, and it also uncovers further possibilites of exploiting tailor made calling conventions of functions. This is described in [Boq95a, Boq95b]. ffl Further transformation is possible (and useful ) on the GRIN code level, such as further inlining of functions, unboxing, and deforestation. ffl Transformations are greatly aided by an analysis of the GRIN code, called constructor analysis, which gives a safe approximation of what pointers ....

....l v; unit v Fsum a l sum a l; v update l v; unit v ( other possible cases . It is perfectly possible and safe to be content with the above GRIN program, and subject it to the low level target code generator register allocator, and still be able to do a fair job with it [Boq95b]. However, the main point of this work is to do some further transformations, notably inlining of EVAL. 2.2 Constructor analysis It is perfectly possible to inline each and every call of EVAL with the body of the EVAL procedure, as described above. However, then each such case would typically ....

[Article contains additional citation context not shown here]

Urban Boquist. Interprocedural Register Allocation for Lazy Functional Languages. Licentiate Thesis, Chalmers University of Technology, Mars 1995.

....known functions. Not only does it eliminate the call overhead of EVAL, it also increases the sise of the code portions voer which variables might usefully reside in registers, and it also uncovers further possibilites of exploiting tailor made calling conventions of functions. This is described in [Boq95a, Boq95b]. ffl Further transformation is possible (and useful ) on the GRIN code level, such as further inlining of functions, unboxing, and deforestation. ffl Transformations are greatly aided by an analysis of the GRIN code, called constructor analysis, which gives a safe approximation of what pointers ....

Urban Boquist. Interprocedural Register Allocation for Lazy Functional Languages. In Proceedings of the 1995 Conference on Functional Programming Languages and Computer Architecture, La Jolla, California, June 1995.

....or binding time analysis for partial evaluation. Sestoft, in [21] however, explores the use of closure information to turn first order analyses into higher order analyses which is close in spirit to our applications were we combine flow information with local information. Recently, Boquist [3], building on earlier work by Johnsson [13] has applied constructor analysis to the optimization of a graph reduction intermediate language. The transformations performed are related to our eval elimination, but the formulation is rather different. Boquist also uses the analysis information to ....

Urban Boquist. Interprocedural register allocation for lazy functional languages. In FPCA'95, 1995.

....or binding time analysis for partial evaluation. Sestoft, in [21] however, explores the use of closure information to turn first order analyses into higher order analyses which is close in spirit to our applications were we combine flow information with local information. Recently, Boquist [3], building on earlier work by Johnsson [13] has applied constructor analysis to the optimization of a graph reduction intermediate language. The transformations performed are related to our eval elimination, but the formulation is rather different. Boquist also uses the analysis information to ....

Urban Boquist. Interprocedural register allocation for lazy functional languages. In FPCA'95, San Diego, California, June 1995.

....to the register variables that satisfy the constraints. Such situations require the register allocator to insert move and or save constructs until the constraints can be solved. This approach is just like the build colorspill cycle in a conventional register allocator based on graph colouring [4, 15]. An example of how this term could be rewritten and allocated is: let f = R1 x: let y = 1 R2 in add R3 R2 R3 x y in let z 1 = 1 R3 in let z 2 = f R1 z 1 in move R4 R3 z 5 = z 2 in let z 3 = 2 R3 in let z 4 = f R1 z 3 in add R4 R3 R1 z 5 z (2) return fac then: fac else: 3) mul r2, ....

Urban Boquist. Interprocedural Register Allocation for Lazy Functional Languages. Licentiate Thesis, Chalmers University of Technology, Mars 1995. URL: http://www.cs.chalmers.se/~boquist/lic.ps.

.... Yorktown allocator , developed by Chaitin and his colleagues at IBM [10, 11] Beside Chaitin s the main influential work is Chow and Hennessy s priority based colouring [13] Starting from either Chaitin or from Chow and Hennessy, many global 1 register allocators have been developed (see [6] for an overview) However, few interprocedural allocators have been presented, mainly because most previous work have been targeted towards imperative languages and therefore naturally interested in making the allocation succeed well on loops (for which global allocation is enough) The ....

....registers. The code is functional and uses a state monad to express sequentiality. Instead of giving a formal semantics for GRIN we will show an example of how a simple program (see Figure 1) can be translated, and explain GRIN constructs as they appear. For more details the reader is referred to [6]. GRIN for the sieve program In [22] an intermediate code called GRIN, Graph Reduction Intermediate Notation, was introduced. It was basically an imperative, procedural version of G machine code, but used local variable names instead of abstract stack locations. As an example, EVAL was seen as ....

[Article contains additional citation context not shown here]

Urban Boquist. Interprocedural Register Allocation for Lazy Functional Languages. Licentiate Thesis, Chalmers University of Technology, Mars 1995.

.... Or, put in another way, what we need, to implement these languages eOEciently, is to minimise the procedure call and return overhead, and doing interprocedural register allocation can be a good method for achieving that [Cho88] Our register allocation algorithm was described in [Boq95a,Boq95b] and, for space reasons we will not explain it in detail here (although it has changed a bit since then) In summary, it is an interprocedural graph colouring algorithm, based on optimistic graph colouring [BCKT89] but with several additions; e.g. interprocedural coalescing and a restricted ....

Urban Boquist. Interprocedural Register Allocation for Lazy Functional Languages. Licentiate Thesis, Chalmers University of Technology, Mars 1995. URL: http://www.cs.chalmers.se/~boquist/lic.ps.

....languages. Or, put in another way, what we need, to implement these languages eOEciently, is to minimise the procedure call and return overhead, and doing interprocedural register allocation can be a good method for achieving that [Cho88] Our register allocation algorithm was described in [Boq95a,Boq95b] and, for space reasons we will not explain it in detail here (although it has changed a bit since then) In summary, it is an interprocedural graph colouring algorithm, based on optimistic graph colouring [BCKT89] but with several additions; e.g. interprocedural coalescing and a ....

Urban Boquist. Interprocedural Register Allocation for Lazy Functional Languages. In Proceedings of the 1995 Conference on Functional Programming Languages and Computer Architecture, La Jolla, California, June 1995. URL: http://www.cs.chalmers.se/~boquist/fpca95.ps.

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