[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