[GHC] #11564: Possible overzealous unfolding

[GHC]

#11564: Possible overzealous unfolding
-------------------------------------+-------------------------------------
        Reporter:  simonmar          |                Owner:  simonpj
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:
       Component:  Compiler          |              Version:  8.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 simonpj):

 Here's the code in `WorkWrap.tryWW`
 {{{
   | not loop_breaker
   , Just stable_unf <- certainlyWillInline dflags fn_unf
   = return [ (fn_id `setIdUnfolding` stable_unf, rhs) ]
         -- Note [Don't w/w inline small non-loop-breaker, or INLINE,
 things]
         -- NB: use idUnfolding because we don't want to apply
         --     this criterion to a loop breaker!
 }}}
 The note says
 {{{
 Note [Don't w/w inline small non-loop-breaker things]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 In general, we refrain from w/w-ing *small* functions, which are not
 loop breakers, because they'll inline anyway.  But we must take care:
 it may look small now, but get to be big later after other inlining
 has happened.  So we take the precaution of adding an INLINE pragma to
 any such functions.

 I made this change when I observed a big function at the end of
 compilation with a useful strictness signature but no w-w.  (It was
 small during demand analysis, we refrained from w/w, and then got big
 when something was inlined in its rhs.) When I measured it on nofib,
 it didn't make much difference; just a few percent improved allocation
 on one benchmark (bspt/Euclid.space).  But nothing got worse.
 }}}
 Also look at `certainlyWillInline`.

 Now, maybe the size calculation is bad, and is treating as small something
 that isn't small. The calculation in `certainlyWillInline` is saying, I
 think, that the size of the RHS is no bigger than the size of the call
 (i.e. `(arity+1)*10`).

 Does that help?

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