[GHC] #9476: Implement late lambda-lifting

[GHC]

#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 simonpj):

 Thoughts

 * There are a handful of spectacular reductions in allocation (queens,
 n-body).  It'd be good to understand and explain them.  Perhaps we can
 more closely target LLF on those cases.

 * I don't think we should float join points at all, recursive or non-
 recursive.  Think of them like labels in a control-flow graph.

 * I think of LLF as a code-generation strategy, that we do once all other
 transformations are done.  (Lambda-lifting ''can'' affect earlier
 optimisations.  It can make a big function into a small one (by floating
 out its guts), and thereby let it be inlined.  But that is subtle and
 difficult to get consistent gains for.  Let's not complicate LLF by
 thinking about this.)

 * Given that it's a code-gen strategy, doing it on STG makes perfect sense
 to me.  You've outlined the pros and cons well. Definitely worth a try.

 I'm not sure what you meant by "It's not enough to look at Core alone to
 gauge allocation" as a disadvantage.

 When you say "Much less involved analysis that doesn't need to stay in
 sync with CorePrep", I think it would be v helpful to lay out "the
 analysis".  I have vague memories, but I don't know what this "stay in
 sync" stuff is about.

 If you do it in STG you don't need to explain "stay in sync", but
 explaining the analysis would be excellent.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9476#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler