[GHC] #1600: Optimisation: CPR the results of IO
GHC
ghc-devs at haskell.org
Tue Dec 10 14:56:28 UTC 2013
#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
More information about the ghc-tickets
mailing list