#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