#12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ryantrinkle): Hmm, that makes a lot of sense. I think we probably would run into that sometimes, although I'm not entirely sure how often. We may be able to factor out these superclasses - in the cases I know of, they're for convenience, not out of necessity. There's a lot I don't understand here, but I do suspect that in our real- world cases, extremely aggressive inlining (like I'm hoping to get working, see https://mail.haskell.org/pipermail/ghc- devs/2016-October/013142.html) may result in enough inlining that this issue doesn't matter. Ideally, I'd like both the subclass and the superclass to be inlined. I'm just worried that sometimes the subclass won't be inlinable, and if that also prevents the superclass from being inlined, that'll make the optimization very brittle. With regard to having the wrong dictionary being passed in, I suppose changing this behavior would lean very heavily on the canonicity of instances - and perhaps would interfere with uses of incoherent instances and such? I'm fairly certain it wouldn't be a problem in any of our code, but I wouldn't want to cause problems for others. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12791#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler