[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