[GHC] #11735: Optimize coercionKind

[GHC]

#11735: Optimize coercionKind
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.3
      Resolution:                    |             Keywords:
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:                    |
-------------------------------------+-------------------------------------

Comment (by tdammers):

 Replying to [comment:20 goldfire]:
 > Thanks for finding `Note [Computing a coercion kind and role]`. I
 believe this note is correct and is as relevant today as it was when I
 wrote it.

 > And, I'm afraid to say that `coercionRole (NthCo ...)` manifestly
 '''does''' require `coercionKind`. See the call in the `where` clause in
 the suggested patch.

 Correct. The original `coercionKindRole` function recursed via the `go`
 worker directly, but now that I have rewritten it as `coercionRole`, the
 `NthCo` case still required the coercion kind to do its thing, so it calls
 `coercionKindRole`, which, post-unrefactoring, calls both `coercionKind`
 and `coercionRole`.

 > However, perhaps the solution lies in including the role of an `NthCo`
 in the `NthCo`, essentially caching this result. I think this would be
 easy to do, especially as the caller of `mkNthCo` generally has to know
 what role its getting -- `mkNthCo` could take this role as a parameter.
 Lint could check that the supplied role is the same as what would have
 been calculated. With this change to `NthCo`, then `coercionRole` really
 would be independent of `coercionKind` and we could separate the
 functions.

 Sounds like a reasonable plan; however, before I venture into implementing
 this, I would love to have some hard evidence that we actually do have a
 problem. Do you have any single-module example code ready that I could use
 to prove that the "un-refactored" code performs significantly worse than
 current HEAD on some inputs?

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