#11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): Btw this is a subset of tests from #11196 which got 30-60% worse after TypeInType.
I do not expect the in-scope set to be evaluated at all (that is, it should remain as a thunk) when substituting into for-all-free types.
I've experimented a bit and you're right. The in-scope set is never forced for T5030. Why do we see a difference then? I've compared: {{{ empty_subst = mkEmptyTCvSubst (pprTrace "forced" (ppr (ty,args)) $ mkInScopeSet $ tyCoVarsOfTypes (ty:args)) }}} with {{{ empty_subst = mkEmptyTCvSubst (pprTrace "forced" (ppr (ty,args)) $ mkInScopeSet $ tyCoVarsOfTypes []) }}} and they performed exactly the same! They were different without `pprTrace`. So I've tried: {{{ empty_subst = mkEmptyTCvSubst (pprTrace "forced" (ppr ()) $ mkInScopeSet $ tyCoVarsOfTypes []) }}} and it was better, back to the same amount of allocations as `baseline`. It appears that the difference in allocations comes from the thunks that get created or `empty_subst` being constant changes the generated code significantly. I will take a look at the core. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11371#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler