[GHC] #9020: Massive blowup of code size on trivial program
GHC
ghc-devs at haskell.org
Tue Apr 22 07:33:07 UTC 2014
#9020: Massive blowup of code size on trivial program
------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.2
Keywords: | Operating System: Unknown/Multiple
Architecture: Unknown/Multiple | Type of failure: None/Unknown
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
------------------------------------+-------------------------------------
The test `simplCore/should_compile/simpl015` was leading to massive
compile times. This is weird: it looks like:
{{{
main = do { return ()
; return ()
... hundreds more times ...
; return () }
}}}
It turns out that the cause was over-eager eta-expansion. Each `return
()` gives a top-level PAP thus
{{{
lvl17 :: IO ()
lvl17 = returnIO ()
}}}
But these definitions are then eta-expanded, thus:
{{{
lvl17 = ((\eta. returnIO () |> sym g) eta) |> g
where g :: State# RealWorld -> (# State# RealWorld, () #)
~
IO ()
}}}
Now in general it makes sense to eta-expand through newtypes (as is done
here), because it exposes more lambadas. But it really doesn't make sense
to eta-expand a PAP like this.
Fortunately the fix is easy: use `exprArity` rather than `manifestArity`
in `SimplUtils.tryEtaExpandRhs`.
The effect on `simpl015` is dramatic: compiler allocation drops from 6.6G
to 812M; and residency drops from 1.8G to 45M.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9020>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list