#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Thanks for your insights! I have to read up on defunctionalisation, but what you suggest is basically what I had in mind in 1. above: Query the free variables of the lambda and see if they are in the [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc236... #diff-992f9a53caac96c0e6303669d68a20e1R2163 ValueEnv] (meaning their RHSs are in WHNF, too). For some reason they weren't present where I expected them, looking into this now.
Should we specialise on (G1 x) or on the deeper pattern (G1 (Yield a b c))? It depends how much f' scrutinises its argument. And you can see that from what applyG does.
Well, I'm not sure we can see that without running some kind of simplification first. But with `SPEC`, the matching `ArgOcc` is irrelevant, so we can look into this later. I [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc236... #diff-992f9a53caac96c0e6303669d68a20e1R1144 conveniently left] `CallOcc` with an `ArgOcc` field for when the result of the call is scrutinised for that. I'll go and see if I can get the free vars of the lambda into the `ValueEnv`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/855#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler