[GHC] #13143: NOINLINE and worker/wrapper

[GHC]

#13143: NOINLINE and worker/wrapper
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by gridaphobe):

 Hi Simon, I'm a bit confused by your simplified example.  On HEAD I get

 {{{
 g =
   \ @ a @ p $dNum $dShow ds p1 ->
     case ds of {
       False ->
         + $dNum (case p1 of { (ds1, y) -> y }) (fromInteger $dNum g1);
       True -> f $dShow p1
     }
 }}}

 No reboxing (or worker) in sight. But if I pattern match on the pair
 inside `g`

 {{{
 g True  (x,y) = f (x,y)
 g False (x,y) = x + 1
 }}}

 I get

 {{{
 $wg =
   \ @ b @ p w w1 w2 ww ->
     case w2 of {
       False -> + w ww (fromInteger w g2);
       True -> f w1 (ww, g1)
     }

 g =
   \ @ b @ p w w1 w2 w3 ->
     case w3 of { (ww1, ww2) -> $wg w w1 w2 ww1 }
 }}}

 which does do the needless reboxing.

 Unfortunately, removing the `isNeverActive` case in `tryWW` does not
 change the result, and glancing through `-dverbose-core2core` it doesn't
 appear that we end up performing W/W on `f`.

 It also doesn't improve the situation for the GHC.Arr example as you've
 written it, though interestingly it '''does''' improve over HEAD if you
 define `indexError` as a simple diverging loop

 {{{
 indexError rng i tp = indexError rng i tp
 }}}

 rather than an explicit `error` call.

 Furthermore, even though the motivating example is not yet improved, there
 are some small gains in nofib

 {{{
 --------------------------------------------------------------------------------
         Program           Size    Allocs   Runtime   Elapsed  TotalMem
 --------------------------------------------------------------------------------
             Min          -0.9%     -0.3%    -16.9%    -24.7%     -2.4%
             Max           0.0%      0.0%    +14.5%    +15.8%     +0.9%
  Geometric Mean          -0.1%     -0.0%     +0.4%     -1.2%     -0.0%
 }}}

 It seems we're on the right track, but there must be another missing piece
 to the puzzle.

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