Re: [GHC] #11284: Lambda-lifting fails in simple Text example

24 Dec 2015

      #11284: Lambda-lifting fails in simple Text example
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.3
      Resolution:                    |             Keywords:
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 bgamari):

 For what it's worth, this binding is caught by the `AnnRec` pattern of
 `SetLevels.lvlBinds` by the `not (profitableFloat ...)` guard. `dest_lvl =
 <1,4>` and `bind_lvl = <1,5>`. `-ffloat-all-lams` and `-ffloat-lam-
 args=10` here doesn't seem to make any difference on the produced Core;
 while the binding gets floated out as one would expect, later simplifier
 phases later push it back in. Even after float-out, however, we still have
 an inner binding,
 {{{#!hs
 poly_$wloop_length_s7fV
   :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# ->
 GHC.Prim.Int# -> GHC.Prim.Int#
 poly_$wloop_length_s7fV =
   \ (dt_a6OV :: GHC.Prim.ByteArray#)
     (a_a6OU :: GHC.Prim.Int#)
     (ww_s7bR :: GHC.Prim.Int#)
     (ww_s7bV :: GHC.Prim.Int#) ->
     (letrec {
        $wloop_length_s7fT :: GHC.Prim.Int# -> GHC.Prim.Int# ->
 GHC.Prim.Int#
        $wloop_length_s7fT =
          \ (ww_X7c8 :: GHC.Prim.Int#) (ww_X7cd :: GHC.Prim.Int#) ->
            case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww_X7cd a_a6OU)
            of wild1_a6P4 {
              False -> ...
              True  -> ww_X7c8
            }; } in
      $wloop_length_s7fT)
       ww_s7bR ww_s7bV
 }}}
 Which later gets inlined back into `$wgo`.

 Looking at this Core, I suppose it's plausible that there really are too
 many free variables in this function to beneficially lambda-lift. It would
 be nice to have a second opinion here.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11284#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler