[GHC] #13353: foldr/nil rule not applied consistently

[GHC]

#13353: foldr/nil rule not applied consistently
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > So it seems that after splitting the function into two pieces, it is
 small enough(?) so that both pieces inline?

 Yes that is galling I agree.

 * Part of the trouble is that strictness analysis does a deep semantic
 analysis, pulls all the evals to the top, inlines them unconditionally,
 leaving behind a worker that may now be a lot smaller.  The `sizeExpr`
 code in `CoreUnfold` is necessarily much simpler.

 * The discount we award for a scrutinised argument is computed in
 `size_up` here:
 {{{
             alts_size (SizeIs tot tot_disc tot_scrut)
                           -- Size of all alternatives
                       (SizeIs max _        _)
                           -- Size of biggest alternative
                   = SizeIs tot (unitBag (v, 20 + tot - max)
                       `unionBags` tot_disc) tot_scrut
 }}}
   For a single-alternative case (and you have a tuple arg here) `tot` =
 `max`, so there's fixed discount of 20.  You could make that into a
 controllable flag and try varying it.

 * Idea.  If a function ''starts'' with `case x of blah` (even if wrapped
 in lets) we know that the strictness analyser will find it strict in x.
 So we know it'll generate a wrapper, and the wrapper will inline.  So in
 the end it'll be as if that case cost nothing at all.  It would not be
 hard to make `sizeExpr` simply count zero for the cost of such cases;
 including nested.  (Certainly for single-alternative ones.)

 Worth a try?

 Simon

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