#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