[GHC] #12370: Implement LetUp in DmdAnal (or document why we do not do it)

[GHC]

#12370: Implement LetUp in DmdAnal (or document why we do not do it)
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 That changeset isn't in the repo.  Perhaps you meant
 [https://git.haskell.org/ghc.git/commitdiff/aa472d7bf13bbeb390e857c95c8b92d90d6246ae
 this one]?

 Yes, that looks like a good change to me; simple and worth doing.  Make
 `isLam` look through casts perhaps.

 I'd had hoped that we could eliminate the `is_thunk` stuff in
 `dmdAnalRhs`, which would make the change a bigger win.  But for recursive
 RHSs we might still see a non-lambda in `dmdAnalRhs`.  But I'm hazy about
 the `trimCPR` and `splitFVs` stuff (which is ill-documented) so it may be
 that for the recursive case we can just do something simpler and more
 conservative.  If we have mutual recursion with a non-lambda, I doubt we
 are going to get much useful.

 There must be simple examples where there really is a win; maybe add one
 as a regression test so we will see if we lose it?

 For the triv-rhs part, there's a bit of fancy footwork in `dmdAnalRhs`
 that you don't seem to be doing here... why?

 Another infelicity in the existing setup.  What about  `foo = g x` where
 `g` has arity 2?  This RHS is a partial application and morally we should
 get the same as `foo = \y. g x y`.  But I doubt we do.  Fixing this might
 be a small win too.  GHC's policy right now is NOT to eta-expand partial
 applications (I forget why; we could consider revisiting that decision).

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12370#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler