[GHC] #4064: SpecConstr broken for NOINLINE loops in 6.13

[GHC]

#4064: SpecConstr broken for NOINLINE loops in 6.13
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:                         
   Component:  Compiler          |      Version:  6.13                   
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------

Comment(by simonpj):

 When GHC generates a specialisation for a function (in `Specialise` or
 `SpecConstr`) it transfers the inline-activation to the new rule.  Thus if
 if you say NOINLINE[1] for the function, the rule will be inactive until
 phase 1, just like the inlining.  Why?  Because you said NOINLINE for a
 reason, probably to make sure that a rule would fire.  Eg
 {{{
 f :: Int -> Int
 {-# NOINLINE[1] f #-}
 f x = ...

 {-# RULE "Blob" forall a.  h (f x) = k x #-}
 }}}
 The NOINLINE makes sure 'f' doesn't get inlined until the RULE has had a
 chance to fire.  And exactly the same goes for any automatically generated
 specialisations of f. We don't want to generate a rule
 {{{
 {-# RULE "Spec" forall x. f (I# x) = $sf x #-}
 }}}
 because firing that rule will prevent rule "Blob" from firing.

 In this case you'd marked the function NOINLINE, so it'll never be inlined
 and its rules will never fire.  You're right that in that case it is
 stupid to generate specialisations that will never be used.  I will fix
 that.

 Mind you, it's a bit odd to have a NOINLINE on a recursive function in the
 first place, isn't it?   GHC doesn't inline recursive functions anyway.
 Perhaps the reason is to make sure rules will fire?

 Your foo=foo' idea is quite attractive, although it seems a little ad-hoc
 (eg NOLININE[1] things are presumably unaffected).  And it's not so clear
 what to do in the case of mutual recursion.  I'm inclined to leave this
 for the programmer to do, at least unless it becomes common.

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