[GHC] #11791: Remove the `isInlinePragma prag` test
What is more mysterious to me is why the unfolding for `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined into it, which would allow a cascade of further improvements, which would, I think, produce essentially the same code as `thenIO`.
The offending corner is this {{{ active_unfolding_gentle id = isInlinePragma prag -- WHY?? && isEarlyActive (inlinePragmaActivation prag) }}} So I tried removing the `isInlinePragma prag` test, and indeed the code becomes identical.
Conclusion: * I'd love to make the above change to `active_unfolding_gentle` and see if any other performance numbers budge. I doubt that anything will change a lot -- it really only affects whether optimisation happens before or after inlining -- but it should improve compiler performance a bit for
#11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11781, #5928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of tickjet:11781#comment:9, where simonpjs writes: that very reason. This could be a separate ticket
Incidentally, see #5928 which is somewhat related.
This ticket tracks that idea. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11791 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11781, #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer, Inlining -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11791#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11781, #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sjakobi: Old description:
This is a spin off of tickjet:11781#comment:9, where simonpjs writes:
What is more mysterious to me is why the unfolding for `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined into it, which would allow a cascade of further improvements, which would, I think, produce essentially the same code as `thenIO`.
The offending corner is this {{{ active_unfolding_gentle id = isInlinePragma prag -- WHY?? && isEarlyActive (inlinePragmaActivation prag) }}} So I tried removing the `isInlinePragma prag` test, and indeed the code becomes identical.
Conclusion: * I'd love to make the above change to `active_unfolding_gentle` and see if any other performance numbers budge. I doubt that anything will change a lot -- it really only affects whether optimisation happens before or after inlining -- but it should improve compiler performance a bit for that very reason. This could be a separate ticket
Incidentally, see #5928 which is somewhat related.
This ticket tracks that idea.
What is more mysterious to me is why the unfolding for `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined into it, which would allow a cascade of further improvements, which would, I think, produce essentially the same code as `thenIO`.
The offending corner is this {{{ active_unfolding_gentle id = isInlinePragma prag -- WHY?? && isEarlyActive (inlinePragmaActivation prag) }}} So I tried removing the `isInlinePragma prag` test, and indeed the code becomes identical.
Conclusion: * I'd love to make the above change to `active_unfolding_gentle` and see if any other performance numbers budge. I doubt that anything will change a lot -- it really only affects whether optimisation happens before or after inlining -- but it should improve compiler performance a bit for
New description: This is a spin off of ticket:11781#comment:9, where simonpj writes: that very reason. This could be a separate ticket
Incidentally, see #5928 which is somewhat related.
This ticket tracks that idea. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11791#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11781, #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * status: new => closed * resolution: => fixed Comment: The offending bit of code was removed in 2effe18ab51d66474724d38b20e49cc1b8738f60. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11791#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC