[GHC] #10260: last uses too much space with optimizations disabled

GHC ghc-devs at haskell.org
Thu Apr 16 22:31:56 UTC 2015


#10260: last uses too much space with optimizations disabled
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                   Owner:  nomeata
            Type:  bug               |                  Status:  patch
        Priority:  normal            |               Milestone:
       Component:  Core Libraries    |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:  Phab:D847
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Re comment:6 I too was surprised that `last` was not eta-expanded.  But
 see this note in `SimplUtils`:
 {{{
 Note [Do not eta-expand PAPs]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 We used to have old_arity = manifestArity rhs, which meant that we
 would eta-expand even PAPs.  But this gives no particular advantage,
 and can lead to a massive blow-up in code size, exhibited by Trac #9020.
 Suppose we have a PAP
     foo :: IO ()
     foo = returnIO ()
 Then we can eta-expand do
     foo = (\eta. (returnIO () |> sym g) eta) |> g
 where
     g :: IO () ~ State# RealWorld -> (# State# RealWorld, () #)

 But there is really no point in doing this, and it generates masses of
 coercions and whatnot that eventually disappear again. For T9020, GHC
 allocated 6.6G beore, and 0.8G afterwards; and residency dropped from
 1.8G to 45M.

 But note that this won't eta-expand, say
   f = \g -> map g
 Does it matter not eta-expanding such functions?  I'm not sure.  Perhaps
 strictness analysis will have less to bite on?
 }}}
 The worse code for the un-eta-expanded code for `last` is perhaps an
 example of the last paragraph!

 And yet the comment is reasonably convincing.  I'm not sure what to do
 here.

 Joachim, one thing that might be worth trying is to eta-expand as far as
 poss without bumping into a coercion.  That would expand `last` but not
 `foo`.  Want to try that?  We may fix `last` but there are sure to be
 other cases, and the more robust the optimisations the better.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10260#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list