#3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -19,1 +19,1 @@ - More details, examples, and an informal spec: wiki:Inlining + More details, examples, and an informal spec: wiki:OldInlining New description: Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner. Unfolding Recursions Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand- unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents. More details, examples, and an informal spec: wiki:OldInlining -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3123#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler