#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