[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 nomeata):

 >  That changeset isn't in the repo. Perhaps you meant ​this one?

 Yes; there is no good stable way to refer to changesets on rebasing
 branches, unfortunately.

 > Make isLam look through casts perhaps.

 As the comment indicates, it mirros the behavior of `collectBinders e`,
 because if `collectBinders` does not find any binders, then LetDown is not
 going to perform well. I will expand the comment to explain this
 reasoning.

 > 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?

 I will produce an example where we can see a difference in the analysis
 result.

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

 I simply don’t handle the case and let it fall through to `dmdAnalRhs`.
 Will add a note, or refactor.

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