[GHC] #14275: Large Haskell value unexpectedly gets an unfolding

GHC ghc-devs at haskell.org
Mon Sep 25 20:39:06 UTC 2017


#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


More information about the ghc-tickets mailing list