[GHC] #12724: Be lazier about reducing type-function applications
GHC
ghc-devs at haskell.org
Mon Oct 17 09:45:16 UTC 2016
#12724: Be lazier about reducing type-function applications
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Description changed by simonpj:
@@ -30,1 +30,3 @@
- and
+
+ Relevant performance tests are `T3064` and `T5030` in `compiler/perf`.
+ Doubtless many others too.
New description:
Consider this:
{{{
f :: F 20 -> F 20
f x = x
}}}
That ought to typecheck in a trice, right? But if `F` is a type function,
GHC currently (8.0) eagerly reduces `F 20` to normal form. Let's say `F
20` unltimately reduces to `Int`, after a long time. Then we get
{{{
f = \x . (x |> g1) |> g2
where
g1 :: F 20 ~ Int
g2 :: Int ~ F 20
}}}
Here both `g1` and `g2` are big coercions. So we waste time reducing `F
20` ''and'' we generate giant coercions by doing so. Maybe the optimiser
gets rid of them again; more probably not. But it's clearly stupid.
This is one reason that the program in #5030 typechecks so slowly. We
have
{{{
cnst :: Integer -> Either (Immediate DummyCPU) (RegVar DummyCPU)
cnst x = Left (Const x)
}}}
and there is absolutely no need to reduce either argument of the `Either`
to normal form.
Richard and I have ideas about how to fix this, but I'm recording it in a
ticket.
Relevant performance tests are `T3064` and `T5030` in `compiler/perf`.
Doubtless many others too.
--
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12724#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list