#9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I'm currently thinking about Pros and Cons involved with (re-)implementing this as an optimization on STG rather than Core. Pros: - Much less involved analysis that doesn't need to stay in sync with CorePrep - LLF only enables intra-module opportunities in the simplifier anyway - Runtime arguments are immediately visible - Lifting to top-level only is orthogonal enough to full laziness that it might be worthwhile to split anyway - Integrating more low-level information might be more feasible (like calling convention, e.g. number of argument registers, or `stg_ap_*` patterns) Cons: - The Simplifier might not be able to inline as much (which probably had limited effect anyway) - It's not enough to look at Core alone to gauge allocation (quite a bummer) - No Core Lint (but STG Lint, still) - Potentially we need to re-invent some utility functions we already have for Core - Perform the lifting by hand, rather than let `FloatOut` do the work I'm really interested to hear opinions/objections about this! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9476#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler