[GHC] #11781: Improve common sub-expression

[GHC]

#11781: Improve common sub-expression
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D2074
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Aha, good work.

 `-fddump-simpl-ticks` might have nailed it earlier; should have though of
 that.  It should show more inlining of `$fApplicativeIO_$c*>` etc, during
 some particular simplifier run; so the result is the same but the journey
 is different.  Does it?

 It's not the casts. It's caused by `Note [CSE for stable unfoldings]`.
 Note that the IO instances of both `>>` and `*>` get INLINE pragams in
 `GHC.Base`, so we are (now) very cautious about inlining them, rightly I
 think.

 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:
  * We could change the code in `GHC.Base` to have
 {{{
 *> = thenIO
 >> = thenIO
 }}}
   No reason why not; it's simple and direct. Does it fix the perf problem
 in the compiler?

 * 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.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11781#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler