[GHC] #9476: Implement late lambda-lifting
GHC
ghc-devs at haskell.org
Mon Jul 9 15:48:55 UTC 2018
#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
More information about the ghc-tickets
mailing list