[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
           Keywords:  Profiling      |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Consider
 {{{
 case (error "blah") of BIG
 }}}
 You'd expect that to simplify to `error "blah"`, or more precisely to
 `case error "blah" of {}`.  And usually it does.

 But if there are ticks around it, it does not, and we retain
 {{{
 case (tick x (error "blah")) of BIG
 }}}
 The problem is in `Simpify.simplTick`.  It calls `splitCont` which
 implements semantics I do not understand.

 The Right Thing is surely this.

 * Always push the tick onto the continuation
 {{{
 simplTick env tickish expr cont
   = simplExprF env expr (mkTickIt tickish cont)
 }}}

 * Implement a suitable `mkTickIt` that pushes a tick past a continuation
 where possible. For example I think
 {{{
 mkTickIt t (ApplyTo arg cont) = ApplyTo arg (mkTickIt t cont)
 }}}
   That is `(tick t e) a` becomes `tick t (e a)`.  It's probably
 conditioned on what sort of tick, but that's fine.

 * The comments from `7bb0447d` (simonmar) say
 {{{
 -- XXX: we cannot do this, because the simplifier assumes that
 -- the context can be pushed into a case with a single branch. e.g.
 --    scc<f>  case expensive of p -> e
 -- becomes
 --    case expensive of p -> scc<f> e
 --
 -- So I'm disabling this for now.  It just means we will do more
 }}}
   But that's wrong.  All we need to do is to ensure that `prepareCaseCont`
 always stops at the kind of tick we don't want to push inside.

 * Finally, the bottom case of `rebuildCall` should retain ticks from the
 continuation.

 Not too hard, but requires understanding of the semantics of ticks, which
 I do not have.

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