[GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1)

[GHC]

#13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1)
-------------------------------------+-------------------------------------
        Reporter:  acowley           |                Owner:
            Type:  bug               |               Status:  merge
        Priority:  normal            |            Milestone:  8.0.3
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  TypeFamilies
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime           |            Test Case:
  performance bug                    |  simplCore/should_compile/T13025
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"b4f2afe70ddbd0576b4eba3f82ba1ddc52e9b3bd/ghc"
 b4f2afe7/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="b4f2afe70ddbd0576b4eba3f82ba1ddc52e9b3bd"
 Fix the implementation of the "push rules"

 Richard pointed out (comment:12 of Trac #13025) that my
 implementation of the coercion "push rules", newly added
 in exprIsConAppMaybe by commit b4c3a66, wasn't quite right.

 But in fact that means that the implementation of those same
 rules in Simplify.simplCast was wrong too.

 Hence this commit:

 * Refactor the push rules so they are implemented in just
   one place (CoreSubst.pushCoArgs, pushCoTyArg, pushCoValArg)
   The code in Simplify gets simpler, which is nice.

 * Fix the bug that Richard pointed out (to do with hetero-kinded
   coercions)

 Then compiler performance worsened, which led mt do discover
 two performance bugs:

 * The smart constructor Coercion.mkNthCo didn't have a case
   for ForAllCos, which meant we stupidly build a complicated
   coercion where a simple one would do

 * In OptCoercion there was one place where we used CoherenceCo
   (the data constructor) rather than mkCoherenceCo (the smart
   constructor), which meant that the the stupid complicated
   coercion wasn't optimised away

 For reasons I don't fully understand, T5321Fun did 2% less compiler
 allocation after all this, which is good.
 }}}

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