[GHC] #11791: Remove the `isInlinePragma prag` test
GHC
ghc-devs at haskell.org
Mon Feb 19 22:20:25 UTC 2018
#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.
New description:
This is a spin off of ticket:11781#comment:9, where simonpj 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.
--
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11791#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list