[GHC] #8095: TypeFamilies painfully slow

[GHC]

#8095: TypeFamilies painfully slow
-------------------------------------+-------------------------------------
        Reporter:  MikeIzbicki       |                Owner:  goldfire
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.4.1
       Component:  Compiler (Type    |              Version:  7.6.3
  checker)                           |
      Resolution:                    |             Keywords:  TypeFamilies
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #5321, #11598,    |  Differential Rev(s):
  #12506                             |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 While I do think your proposed solution may fix the problem reported here
 -- slow compilation -- in my opinion it throws the baby out with the
 bathwater. Using `mkUnsafeCo` should happen only from `unsafeCoerce#`.
 There's nothing unsafe going on here, yet the Core code will be littered
 with what appear to be unsafe coercions.

 Instead of abusing the current unsafe coercions, the plan above is to
 introduce a new `OmittedCo` (controlled by `-f` flags) that is quite like
 `UnsafeCo` (but stores used coercion variables, for instance). Then, when
 reading the Core, we can tell the difference between the product of
 `unsafeCoerce#` and something omitted.

 By the way, I say "may fix" above because this approach might still create
 the coercion, only to throw it away. If we prevent the creation of the
 coercion a little earlier, we might have more luck.

 By the way, I'm sorry to rain on your parade a bit here. I do very much
 appreciate your just going in to fix this... but I don't think the simple
 solution here is quite the right approach that will continue to work in
 the long term.

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