[GHC] #6087: Join points need strictness analysis

[GHC]

#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