[GHC] #10346: Cross-module SpecConstr
GHC
ghc-devs at haskell.org
Sun May 13 08:06:05 UTC 2018
#10346: Cross-module SpecConstr
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: ckoparkar
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.1
Resolution: | Keywords: SpecConstr,
| newcomer
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: #13016 | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by sgraf):
Replying to [comment:18 ckoparkar]:
> Now that I'm looking at the proper thing, I'm a bit confused and have
the same question as ak3n did.
I blame the example.
1. After SpecConstr runs on M, the call isn't really recursive anymore:
There will be a specialisation for the call pattern `[x, y] |> [True, (x,
y)]`. The resulting function is non-recursive, inlined, and suddenly foo
itself isn't recursive anymore and simply gets inlined in X.
2. The `baz` binding in M will make it so that there is a specialisation
for the call pattern `[x,y] |> [False, (x,y)]` anyway. The call in X
matches this pattern, so will be specialised appropriately.
Try this instead:
{{{#!hs
module M where
{-# INLINABLE foo #-}
foo 0 y = y
foo n y = foo (n-1) y
--baz = foo 14 (2,2)
---------------------
module X where
import M
bar = foo 2 (3,4)
}}}
This works better, because integer literals are not currently considered
values (probably to avoid code bloat through endless loop unrolling).
Notice that the call in X specialises iff you comment in `baz` in M which
has the same call pattern.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10346#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list