[GHC] #13374: Let exprSize ignore case analysis

[GHC]

#13374: Let exprSize ignore case analysis
-------------------------------------+-------------------------------------
           Reporter:  nomeata        |             Owner:  (none)
               Type:  task           |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 This came out of a discussion at #1335, where Simon says:

 > >    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?

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