Re: [GHC] #1600: Optimisation: CPR the results of IO

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Trac seems to think I write too much, just lost a somewhat long text here :-(. I was explaining why nested CPR kills a let-no-espcape in this code taken from `scs`’s `LinearAlgebra`: {{{ #!haskell v_zipWith :: (a -> b -> c) -> Array Int a -> Array Int b -> Array Int c v_zipWith f a b | compatible = listArray (bounds a) (zipWith f (elems a) (elems b)) | otherwise = error "error" where compatible = bounds a == bounds b }}} Point taken, I’ll be brief: CPR can kill the no-let-escape property; hence more CPR kills more of that. The problem occurs if the `$j` gets a more detailed CPR type than the expression it is part of, or the expression is somewhere where CPR w/w cannot happen (e.g. in an argument to `runStRep`). This problem is not new and some work-arounds for it exist in the current code (`[CPR for Sun types]`). But maybe this needs a generally better story. (Sidenote: Inlining `runSTRep` would have helped here, but was disabled by simonmar in 920dbbddf57ff02e0734943bb93dd4cecc5568e0/base.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/1600#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC