#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): Work in progress in branch `wip/T12370`. It already works in this simple case: {{{ foo :: (Int, Int) -> Int foo (x,y) = x + y {-# NOINLINE foo #-} bar n m = let p = (n,m) {-# NOINLINE p #-} in foo p }}} Here, bar now gets the very detailed signature `<S(S),1*U(U)><S(S),1*U(U)>m` instead of just `<L,U><L,U>m`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12370#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#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

#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):

I will separately measure if this increases the number of thunks determined to be one-shot. But even if it did, it does not matter much, as shown by nofib.

Again, only insignificant changes, not worth mentioning. The number of thunks in total goes up by 0.06%, precision of the analysis is now 24.9% instead of 24.8%. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12370#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#12370: Implement LetUp in DmdAnal (or document why we do not do it) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: patch 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): Phab:D2395 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner <mail@…>): In [changeset:"45d8f4eb2bf2fcb103517d064e7ba1e491a66f4c/ghc" 45d8f4eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45d8f4eb2bf2fcb103517d064e7ba1e491a66f4c" Demand analyser: Implement LetUp rule (#12370) This makes the implementation match the description in the paper more closely: There, a let binding that is not a function has first its body analised, and then the binding’s RHS. This way, the demand on the bound variable by the body can be fed into the RHS, yielding more precise results. Performance measurements do unfortunately not show significant improvements or regessions. Differential Revision: https://phabricator.haskell.org/D2395 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12370#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler