[GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker

[GHC]

#13014: Seemingly unnecessary marking of a SpecConstr specialization as a
loopbreaker
-------------------------------------+-------------------------------------
        Reporter:  nfrisby           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  SpecConstr
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nfrisby):

 Replying to [comment:9 simonpj]:
 > Can you be more specific about "try very hard"?  The thing is, as far as
 I can see, it ''is'' loop breaker, as my comment shows.  That is, not
 marking it as such would allow arbitrary inlining.

 My basic thought is that `DEEP_SPEC` is to `SPEC` as `SPECIALIZE INLINE`
 is to `SPECIALIZE`. (Thus, `SPEC_INLINE` might be a better/more consistent
 name than `DEEP_SPEC`.)

 The hypothetical power user would intentionally choose `DEEP_SPEC` instead
 of `SPEC` specifically to allow arbitrary inlining. With `SPEC` (i.e.
 normal `-fspec-constr`), GHC assumes the burden of ensuring that the
 specialization cannot lead to an infinite loop. By choosing `DEEP_SPEC`,
 the user intentionally transfers this burden from GHC to themselves. The
 docs for `DEEP_SPEC` would include a warning similar to those already
 present for `SPECIALIZE INLINE` ("Warning: you can make GHC diverge by
 using SPECIALISE INLINE on an ordinarily-recursive function") and `RULES`
 ("GHC makes no attempt to make sure that the rules are confluent or
 terminating. For example: ... This rule will cause the compiler to go into
 an infinite loop.").

 `DEEP_SPEC` would be a tool for the power user who wrote the `f` and `boo`
 functions you came up with and ''did'' want GHC to inline `f` 7 times so
 that `boo` was identified as `0` at compile-time.

 In terms of mechanism, I don't have enough command of `OccAnal` to be much
 more specific. My basic idea is that it wouldn't mark the specializations
 as a loopbreaker unless 1) the specialization ''directly calls itself by
 name'' or 2) for whatever reason, `OccAnal` has no other choice. In other
 words, GHC would only mark a `DEEP_SPEC` specialization as a loopbreaker
 if it concluded that not doing so would ''always'' lead to an infinite
 inlining --- "possibly infinite inlining" would no longer be cause enough
 to mark a particular specialization as a loopbreaker.

 I'll mention one last time that I do not have a real-world motivation for
 this new behavior in-hand. It doesn't seem like an obviously bad idea
 (buoyed by saying "power user" and "warnings in the docs"). But it's also
 not obviously better than all currently existing choices for this
 hypothetical power user! I just haven't thought about this long enough
 yet.

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