#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?
For the triv-rhs part, there's a bit of fancy footwork in dmdAnalRhs
I will produce an example where we can see a difference in the analysis result. 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