Re: [GHC] #9279: Local wrapper function remains in final program; result = extra closure allocation

7 Sep 2018

      #9279: Local wrapper function remains in final program; result = extra closure
allocation
-------------------------------------+-------------------------------------
        Reporter:  simonmar          |                Owner:  simonpj
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.8.2
      Resolution:                    |             Keywords:  LateLamLift
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 sgraf):

 The current tip of my lambda lifting branch will not lift `$wa4`, because
 that would result in a top-level function with 7 parameters, which is two
 more than available hardware registers.

 Since the above link with the reproduction is offline, I had to
 delete/rename stuff from the original reproduction until it compiled again
 myself, but I think I have identified the binding which corresponds to the
 old `$wa4`:

 {{{
 let {
   $wlvl_smyy =
       sat-only \r [w_smyz
                     ww_smyA
                     ww1_smyB
                     ww2_smyC
                     ww3_smyD
                     void_X1V]
           case
               readMutVar# [ipv7_smyu void#]
           of
           { Unit# ipv11_smyH ->
                 case ipv11_smyH of {
                   IVarFull _ -> lvl12_rmt8;
                   IVarEmpty dt2_smyL ->
                       let {
                         sat_smyM =
                             CCCS IVarFull! [w_smyz];
                       } in
                         case
                             writeMutVar# [ipv7_smyu
                                           sat_smyM
                                           void#]
                         of
                         s2#_smyN
                         { (##) ->
                               case
                                   readMutVar# [dt2_smyL
                                                 void#]
                               of
                               { Unit# ipv13_smyQ ->
                                   <the previous go loop was
                                    inlined a few times>
                               };
                         };
                 };
           }; } in
 let {
   lvl20_smz3 =
       \r [w_smz4 w1_smz5 w2_smz6 void_X1U]
           case w2_smz6 of {
             SchedState ww1_smz9
                         ww2_smza
                         ww3_smzb
                         ww4_smzc ->
                 $wlvl_smyy
                     w_smz4
                     ww1_smz9
                     ww2_smza
                     ww3_smzb
                     ww4_smzc
                     void#;
           }; } in
 }}}

 There's also this debug output:

 {{{
 stgLiftLams:goodToLift
   [$wlvl_smyy]
   args spill on stack
 }}}

 Which tells me that it won't lift entirely due to `$wlvl` taking to many
 parameters. Which is a shame, because it's pretty clear that 3 parameters
 are absent. I suspect some Demand Analyser / WW thing at fault here.

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