[GHC] #15090: Do more coercion optimisation on the fly
#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 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: -------------------------------------+------------------------------------- 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15090 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Comment (by tdammers): I tried to figure out how to do this, but I'm a bit confused - `mkTransCo` takes two coercions and builds a `TransCo` from them, but IIUC, the optimisation we're talking about should detect suitable `NthCo`'s and turn them into `AppCo`s. So I don't quite understand why this needs to be done in `mkTransCo` rather than `mkNthCo`. Or should `mkTransCo` drill down into its arguments and perform the optimisation on those? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15090#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
participants (1)
-
GHC