GitLab

While working on #14272 (closed) 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.

Trac metadata

Trac field	Value
Version	8.2.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	low
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture