#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