[GHC] #15090: Do more coercion optimisation on the fly

[GHC]

#15090: Do more coercion optimisation on the fly
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:  Coercions
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by simonpj:

Old description:

> When studying #15019, I looked at `CoreOpt.pushCoValArg`.  I saw lots of
> attempted decompositions in `pushCoValArg`,
> which were trying to do `decomposeFunCo` on
> {{{
>     C @g1 ; sym (C @g2)
> where
>     axiom C a = a -> a
> }}}
> But the smart `mkNthCo` can't make progress on this, so we get
> {{{
>    Nth:2 (C @g1 ; sym (C @g2))
> }}}
> and these things stack up if there is a chain of applications in
> `Simplify.simplCast`.
>
> The coercion optimiser will optimise this coercion to
> {{{
>    (g1 ; sym g2) -> (g1 ; sym g2)
> }}}
> and now the smart `mkNthCo` in `decomposeFunCo` will succeed.
>
> Possible idea: make this optimization part of `mkTransCo` so that it
> happens on the fly.

New description:

 When studying #15019, I looked at `CoreOpt.pushCoValArg`.  I saw lots of
 attempted decompositions in `pushCoValArg`,
 which were trying to do `decomposeFunCo` on
 {{{
     C @g1 ; sym (C @g2)
 where
     axiom C a = a -> a
 }}}
 But the smart `mkNthCo` can't make progress on this, so we get
 {{{
    Nth:2 (C @g1 ; sym (C @g2))
 }}}
 and these things stack up if there is a chain of applications in
 `Simplify.simplCast`.

 The coercion optimiser will optimise this coercion to
 {{{
    (g1 ; sym g2) -> (g1 ; sym g2)
 }}}
 and now the smart `mkNthCo` in `decomposeFunCo` will succeed.

 Possible idea: make this optimization part of `mkTransCo` so that it
 happens on the fly.

 (Annoyingly, I can't remember which of the three test cases mentioned in
 #15109 displayed this behaviour.)

--

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