[GHC] #5945: Lambda lifting

[GHC]

#5945: Lambda lifting
---------------------------------+------------------------------------------
    Reporter:  simonpj           |       Owner:                  
        Type:  bug               |      Status:  new             
    Priority:  normal            |   Milestone:                  
   Component:  Compiler          |     Version:  7.4.1           
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------
 Dan Rosen asks whether GHC has a lambda lifter.  Yes, it does: GHC's full-
 laziness pass also doubles as a lambda lifter

  * It's controlled by the `floatOutLambdas` field of
 `CoreMonad.FloatOutSwitches`
  * This in turn is set from the `floatLamArgs` field of `DynFlags` in
 `SimplCore`
  * The `DynFlags` are set in module `DynFlags` (see `-ffloat-all-lams`,
 `-ffloat-lam-args`)

 However on trying a small experiment on
 {{{
         f x = map (\y -> (x,y))
 }}}

 I see a bug and an infelicity.

  * Bug: the comment with the `floatOutLambdas` field definition claims
 that `Nothing` means float all lambdas to the top.  But the code in
 `SetLevels.destLevel` treats `(Just 0)` and `Nothing` identically, which
 contradicts the comment. Workaround: use `(Just 100)`

  * Infelicity: with `-ffloat-lam-args=100` we get
 {{{
 lvl_sdQ =
   \ (@ t_acm) (@ t_acn) (x_a9H :: t_acm) (y_a9I :: t_acn) ->
     (x_a9H, y_a9I)

 Foo.f =
   \ (@ t_acm)
     (@ t_acn)
     (x_a9H [Dmd=Just L] :: t_acm)
     (eta_B1 :: [t_acn]) ->
     GHC.Base.map
       @ t_acn @ (t_acm, t_acn) (lvl_sdQ @ t_acm @ t_acn x_a9H) eta_B1
 }}}
  which is good, but then the next simplifier run inlines it straight back
 in again, via `SimplUtils.preInlineUnconditionally`.

  I think `preInlineUnconditionally` should be a bit less gung-ho, perhaps,
 but I don't want to change it until I've see if there are any performance
 regressions.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5945>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler