#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 ckoparkar): It turns out that I was comparing the Core output of the regular Specializer instead of SpecConstr. Now that I'm looking at the proper thing, I'm a bit confused and have the same question as ak3n did. Even if I just use GHC HEAD, it seems that the call to `foo` in a different module is specialized. Using the same example with modules `M` and `X`, and compiling it with: `ghc-stage2 -O2 -fforce-recomp -ddump-spec -fspec- constr -fno-specialize X.hs`, this is what `bar` looks like after SpecConstr runs: {{{ bar :: (Integer, Integer) [LclIdX] bar = case $wfoo1_s1h9 GHC.Types.False ww_s1h3 ww_s1h4 of { (# ww_s1ha, ww_s1hb #) -> (ww_s1ha, ww_s1hb) } }}} (This is exactly what the last paragraph in the `Note [Seeding top-level recursive groups]` says should happen. There's a specialized copy of `foo` in the importing module. Or that's what I think it is.) I feel like I'm making a dumb mistake and I'm trying to track this down. mpickering: Do you remember if you were using some specific example while working on that patch ? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10346#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler