[GHC] #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop...

[GHC]

#12808: For closures, Loop Invariant Code Flow related to captured free values not
lifted outside the loop...
-------------------------------------+-------------------------------------
        Reporter:  GordonBGood       |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  JoinPoints
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:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > As I have stated, I believe there are many use cases, even to the common
 worker/wrapper pattern that seeks to reduce the amount of parameter
 passing by enclosing a recursive worker closure inside a wrapper; any
 gains from this pattern could be cancelled and more if the wrapped
 enclosure is less efficient.

 Let me say what I ''think'' you are saying.  Consider
 {{{
 f x p q = let g y = ...g y'...x...
           in (g p, g q)
 }}}
 Left as-is we allocate a closure for `g` every time we call `f`.  But
 instead we could lambda-lift `g`:
 {{{
 g2 x y = ...g2 x y'...x...

 f x p q = (g2 x p, g2 x q)
 }}}
 Now we don't allocate a closure for `g`.  That is good.  Is this what you
 mean?

 We don't want to do this in general, early in optimisation, because we get
 huge benefits from being able to "see" the binding site of `g`'s free
 variable `x`.  But these benefits are over when it comes to code
 generation.

 So we have experimented with so-called "late lambda lifting" (LLF).
 There's a whole wiki page about it: [wiki:LateLamLift].  It can be a real
 win.

 One obstacle to LLF is, ironically, that it can destroy join points (see
 the wiki page).  A second benefit of Luke's new join-point work is that it
 becomes much easier to ensure that LLF doesn't destroy join points, and
 thus renders it much more practical.  I think Luke will turn his attention
 to it once join points are solidly in.

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