#14275: Large Haskell value unexpectedly gets an unfolding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While working on #14272 I was surprised to find that modifying `PrelRules` resulted in a great deal of recompilation. Afterall, it has only three exports: * `primOpRules`: A function headed by a rather large case analysis totaling a few hundred lines of code * `builtinRules`: A large `[CoreRule]` (consisting of a literal list with six entries concatenated with the much-larger `builtInIntegerRules`) * `caseRules`: A function of moderate size Intuitively, none of these things seemed particularly beneficial to inline. This is why I was slightly surprised to find that `builtinRules` (and all of its floated entries) had an unfolding, {{{ builtinRules :: [CoreRule] {- Strictness: m2, Unfolding: (: @ CoreRule builtinRules255 builtinRules1) -} }}} Of course, determining whether unfoldings are helpful is in general quite difficult. However, I can't help but wonder whether our heuristic isn't quite right. Afterall, the Haskell for `builtinRules` is quite large and consequently most users would be surprised to see GHC try to inline it. The only reason it looks so small is that GHC broke up the structure via float-out. I don't have any concrete ideas for addressing this at the moment but felt like I should write down the concern so it isn't lost. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14275 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler