[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 simonpj):

 Ah I see.  Consider
 {{{
 f [] = 0
 f (x:xs) = f xs

 boo = f [1,2,3,4,5,6,6]
 }}}
 Would you expect `f` to inline 7 times in the RHS of `boo` yielding `0`?
 Maybe it'd be good, but GHC doesn't do that, because inlining a recursive
 function repeatedly can make the compiler loop at compile time, or just to
 arbitrary code growth.  Yet in this case it's good.

 In your example we have
 {{{
 lengthVL_$slengthVL
   = ...
     case lengthVL @ k @ as sPEC_XyR sc_sCE of wild_Xc { __DEFAULT ->
     ...
 }}}
 and a RULE
 {{{
 "SC:lengthVL0"
     forall ...
       lengthVL @ k @ (a : as) sc1_sCC
                (GADTSpecConstr.VLS ...)
       = lengthVL_$slengthVL @ k @ a @ as sc_sCE sc1_sCC
 }}}
 So if I inline `lengthVL_$slengthVL` I might create an opportunity for the
 RULE to fire; which gives ries to a new call of `lengthVL_$slengthVL`, and
 the whole process repeasts.  Perhpas indefinitely.

 It's all very much like the `f/boo` case above, and for that reason GHC
 marks `lengthVL_$slengthVL` as a loop breaker.

 There is extensive commentary under `Note [Choosing loop breakers]` in
 `OccurAnal`.

 I wish I knew how to make this better, but I don't.  Yet anyway.

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