#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