[GHC] #8668: SPECIALIZE silently fails to apply

[GHC]

#8668: SPECIALIZE silently fails to apply
-------------------------------------+----------------------------------
        Reporter:  crockeea          |            Owner:
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.6.2
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  x86_64 (amd64)
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+----------------------------------

Comment (by simonpj):

 Thanks that's helpful. I can now at least compile it.


 One complicating factor is that you have a `Num` instance for `FastCyc`.
 You could simplify the setup by calling `plusFastCyc` in
 `cyclotomicTimeTest`, and defining
 {{{
 plusFastCyc :: Num (t r) => FastCyc t r -> FastCyc t r -> FastCyc t r
 plusFastCyc (PowBasis v1) (PowBasis v2) = PowBasis $ v1 + v2
 plusFastCyc p1@(DecBasis _) p2@(PowBasis _) = (g p1) + p2
 plusFastCyc p1@(PowBasis _) p2@(DecBasis _) = p1 + (g p2)
 plusFastCyc p1 p2 = (g p1) + (g p2)
 }}}
 Now you can write your specilise pragmas (or not) for that.  Do you get
 the same behaviour?  That would elminate one source of complexity.

 Can you say in more detail what you ''expect'' to happen?  The slow
 version (could we call it `slow` rather than `cyclotomicTimeTest`?)
 iterates `plusFastCyc` which necessariliy does a lot more work unpacking
 and packing those `PowBasis` constructors. Are you ok with that?  But you
 aren't ok with ''something''.

 In short, it's a bit complicated for me to understand the problem.

 Maybe you can show some `-ddump-simpl` core and say "this call here should
 be specialsed, why doesn't the rule fire?

 Incidentally, if you want GHC to auto-specialise an '''imported'''
 function, to types that may not even be in scope in the defining module,
 you should mark that function as `INLINABLE`

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