[GHC] #13289: Terrible loss of optimisation in presence of ticks

[GHC]

#13289: Terrible loss of optimisation in presence of ticks
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  Profiling
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonmar):

 `splitCont` looks like it separates out any outer type applications and
 coercions from the continuation, so in `(a,b) = splitCont c`, `a` is a
 continuation that consists only of the outer type applications and
 coercions from `c`, and `b` is the rest of the continuation.

 In order to transform `(tick t e) a` into `tick t (e a)`, the conditions
 should be

 * Either `a` is a type, or
 * `tickishScopesLike t NoScope`

 the second condition says that we must not float things in or out of the
 tick. (This `tickishScopesLike` thing is Peter's, I'm not all that
 familiar with it but I think this is right)

 The other thing that the current code is doing is pushing coercions inside
 the tick, which is always safe (and probably a good idea, given that I
 made it do this before).

 But it's slightly strange that this code appears to be lifting ticks out
 of type applications, whereas `CoreUtils.mkTick` is doing exactly the
 opposite!  I have no idea why.  The semantics wouldn't tell us; both are
 safe to do (like, say, floating a `let` outside an application), it's just
 a question of which one gives the best results.  There are a couple of
 things we can do here:

 - Run the profiling tests in `testsuite/tests/profiling`
 - Run nofib with profiling on

 So I suggest making the change you propose, put it up on Phab, and also
 run the tests and nofib to check whether the changes don't introduce
 obvious regressions.

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