#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. Some thoughts * CPR for sum types was introduced in #5075. * The initial motivation was for non-recursive types like `Maybe` and `Either`. Here it seems quite likely that the caller will case-analyse the result, so exposing the result constructor to the caller is good. * You point out that for recursive types, like lists, we typically ''don't'' case-analyse the result, so nothing is gained by the CPR. Maybe we should disable CPR for ''recursive'' sum types. * It's hard to come with a rigorous notion of what a "recursive" sum-type is, but any reasonable approximation will do. * Disabling CPR for `late-dmd-anal` seems unprincipled, and doesn't catch the cases described in #5075. * I note that comment:10 of #5075 identifies that the transformation is switched off for non-top-level definitions. See `Note [CPR for sum types]` in `DmdAnal`. But now that we have join points, the objection may no longer apply. It'd be interesting to try. * comment:12 of #5075 identifies three more tickets that claim to benefit from `late-dmd-anal`. Let's see if they do. * `cse` and `circsim` really do allocate (a little) more. But in your investigation you didn't find any allocation differences. Doesn't `-ticky` nail it for you? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/6087#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler