[GHC] #8668: SPECIALIZE silently fails to apply
#8668: SPECIALIZE silently fails to apply ----------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I have a small example where GHC refuses to specialize a call to `(+)`, compiling with -O2. The two files are Foo.hs (http://lpaste.net/98464) and Main.hs (http://lpaste.net/98342). There seem to be two problems: 1. The active `SPECIALIZE` pragma should be applied, but isn't. This can be seen by comparing the core and runtimes of `fcTest` (slow) vs `vtTest` (fast). I need this version of the pragma in my real code as the phantom type `m` is reified, so I need to specialize the vector code without specifying the phantom type. 2. I can get `fcTest` to run fast if I use the commented-out `SPECIALIZE` pragma instead. However, that pragma seems very straightforward to me (all types are concrete). The docs indicate that GHC should automatically specialize in most cases, why does it not specialize to the commented-out signature automatically? This problem is also posted here: http://stackoverflow.com/questions/21071706/specialization-with- constraints -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): I should be clear: GHC generates specialized code and a rule to apply it, but the rule does not fire. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): Where are `runRand` and `liftRand` defined? Hoogle can't find either. Google finds package `MonadRandom` on hackage, [http://hackage.haskell.org/package/MonadRandom-0.1.3/docs/Control-Monad- Random.html here], but I can't see `liftRand`. Would it be possible to rejig the example so that it doesn't use this extra package? Makes it much easier to reproduce. You don't, presumably, actually need random numbers to demonstrate the bug. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): Right you are. The links are fixed now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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 crockeea): I updated the files again per your suggestion, and get identical behavior. I expect the `vtTest` (currently fast) and `fcTest` (currently slow) to have the same runtime, e.g. < 2 seconds runtime difference. The two functions are doing the same work, but `fcTest` has one more level of indirection (one more wrapper on the type, and one more function call per addition). As far as "doing a lot of work unpacking `Pow` constructors", `plusFastCyc` is iterated 100 times, but the runtime difference is 1 minute 18 seconds. I'm willing to pay for 100 function calls, but I think we can agree that something more is going on than just unpacking constructors. I put some core snippets here [http://lpaste.net/98593] This was compiled with -O3 using the `forall`'d SPECIALIZATION. On line 10, you can see that GHC does write a specialized version of `plusFastCyc`, compared to the generic version on line 167. The rule for the specialization is on line 225. I believe this rule should fire on line 270. (`main6` calls `iterate main8 y`, so `main8` is where `plusFastCyc` should be specialized.) In regards to GHC auto-specializing: if I do not explicitly specialize `plusFastCyc` at all (but still mark it as `INLINABLE`), `fcTest` is slow. If instead I specialize `plusFastCyc` with concrete types as in the comment, `fcTest` is fast. Thus it appears GHC is *not* auto-specializing `plusFastCyc`, despite it being marked as `INLINABLE`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): Inlinable is known to prevent specialization from firing. (unless my recollection is wrong, has something to do with the order of the relevant passes in ghc afaik) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
Inlinable is known to prevent specialization from firing. (unless my recollection is wrong, has something to do with the order of the relevant
#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 crockeea): Replying to [comment:6 carter]: passes in ghc afaik) I tried removing the `INLINABLE`s, but that didn't help. I was under the impression that at least for auto-specialization across modules, `INLINABLE` is ''required''. I've also tried playing around with phase control (just a little) to avoid inlining/specialization order problems, but I couldn't get that to work either. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): If you write the SPECIALIZE pragma instance in the defining module for the operation (assuming the associated class instances specialize too, check that they can specialize mebe?), you don't need the INLINEABLE (unless you want other instances to be specialized). what happens when you go one step in the other direction and use INLINE? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): For the small example above, GHC simply inlines everything and both main functions are equally fast. However, I tried this in my real code and the equivalent of plusFastCyc is too large for GHC to inline (even with `INLINE` pragmas), and used in too many places for that to be a good solution even if it did work. That's why I'm trying to make GHC call a specialized function instead. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): did you try doing a specialize on (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) without the class constraint? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): Replying to [comment:10 carter]:
did you try doing a specialize on
(FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int)
without the class constraint?
If I remove the constraint, the specialization occurs. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): do you get the desired specialization behavior now? If so, i suppose that means maybe theres need for clearer support tooling around understanding specialization pragmas? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): Replying to [comment:12 carter]:
do you get the desired specialization behavior now?
If so, i suppose that means maybe theres need for clearer support tooling around understanding specialization pragmas?
No, I need the specialization to fire ''with'' the constraint. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): why? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): could you walk me through why {{{ {-# SPECIALIZE plusFastCyc :: (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) #-} }}} isn't satisfactory? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): In real code, `plusFastCyc` will call a function in class `Factored`. The function in `Factored` and the call to it in `plusFastCyc` were removed because they weren't needed to demonstrate the specialization problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): Replying to [comment:15 carter]:
could you walk me through why {{{ {-# SPECIALIZE plusFastCyc :: (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) #-} }}} isn't satisfactory?
I added some more code to demonstrate something more like a real use case for the program: http://lpaste.net/98840. It has the same issue as `Foo.hs` above, but hopefully you can see why the constraint is needed. I wanted to remove it from the example to show that the problem wasn't type families, constraint kinds, etc. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): *bump* Any ideas as to why GHC isn't applying the rule in `main8`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): Replying to [comment:4 simonpj]:
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`
I have been playing around with this some more, and found something interesting. As I mentioned, despite the fact that I have everything marked `INLINABLE`, GHC was *not* auto-specializing `plusFastCyc`. However, if I partially apply the call to `plusFastCyc` in Main to `iterate (plusFastCyc y) ...` instead of `iterate (\x -> plusFastCyc y x) ...`, GHC *does* automatically specialize the call to `plusFastCyc`. However, the code is still slow because `(+)` is still not specialized. I might expect (+) to be specialized for two reasons 1. It is called at the top level in Main.hs in the `foldl`. 2. The docs say that *when* there is an explicit pragma, specialization is transitive. I could hope that auto-specialization is also transitive. Is this the case? Is the problem of GHC specializing the partially applied function but not the fully applied version related to ticket:8099? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 carter): any function marked inlineable or inline wont get specialize. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 crockeea): Replying to [comment:20 carter]:
any function marked inlineable or inline wont get specialize., or at least i seem to recall theres some phase ordering issues related to that.
That's in direct contradiction to the docs ("However if a function f is given an INLINABLE pragma at its definition site, then it can subsequently be specialised by importing modules"), and to Simon's comment above. Furthermore, removing "INLINABLE" doesn't help matters. Sure there can be phase issues, but the point is inlining is not occurring at all, so in particular it is not happening in place of specialization. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug Comment: crockeea: do you get the same results with 7.8.3? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8668: SPECIALIZE silently fails to apply -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by crockeea): * version: 7.6.2 => 7.8.3 Comment: Yes, I get the exact same behavior in 7.8.3. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8668: SPECIALIZE silently fails to apply -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I've got lost here. Would it be possible to start from zero: that is, attach to this ticket the smallest reproducible test case you have, along with instructions for how to reproduce it? Thanks. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8668: SPECIALIZE silently fails to apply -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8668#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8668: SPECIALIZE silently fails to apply
-------------------------------------+-------------------------------------
Reporter: crockeea | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.3
Resolution: | Keywords: Inlining
Operating System: Unknown/Multiple | Architecture: x86_64
Type of failure: Runtime | (amd64)
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by nfrisby):
Executive summary: It looks like the expected optimization is achieved in
GHC 7.10.2. I don't know if something was broken and is now fixed or if
some other change side-stepped the original problem, etc. etc.
In GHC 7.10.2, `fcTest` seems to be ''faster'' than `vtTest` (5
repetitions, using the same `-O3` setting that crockeea used); that's a
reversal of the originally discussed behavior.
Compiling `Foo.hs` yields the following rule, which fires when compiling
`Main.hs`, in spite of the dfuns on the LHS (see #7080).
{{{
------ Local rules for imported ids --------
"SPEC plusFastCyc" [ALWAYS]
forall (@ m_a3Ai)
($dFactored_a3Aj :: Factored m_a3Ai Int)
($dVector_a3Bz :: V.Vector U.Vector Int).
plusFastCyc @ (VT U.Vector m_a3Ai)
@ Int
(Foo.$fNumVT
@ U.Vector
@ m_a3Ai
@ Int
(GHC.Real.$p1Real
@ Int
(GHC.Real.$p1Integral
@ Int
($dFactored_a3Aj
`cast` (Foo.NTCo:Factored[0]
participants (1)
-
GHC