[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