#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/aa472d7bf13bbeb390e857c95c8b92d90... 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