[GHC] #15070: postInlineUnconditionally is too eager

[GHC]

#15070: postInlineUnconditionally is too eager
-------------------------------------+-------------------------------------
           Reporter:  simonpj        |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:  8.6.1
          Component:  Compiler       |           Version:  8.2.2
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 In `nofib/spectal/mate`, look at `Move.moveDetailsFor`.  In this
 function we inline a local definition
 {{{
   bd = Board.rmPieceAt c_a25I sq_a2np bd_a25J
 }}}
 into two branches of a case (to hopefully avoid allocating it).  I
 think this is `postInlineUnconditionally`. But then it is floated out
 and has to be laboriously CSE'd again!

 Maybe `postInlineUnconditionally` should be less aggressive.
 To quote the comment:
 {{{
         -- So the main target is things like
         --      let x = f y in
         --      case v of
         --         True  -> case x of ...
         --         False -> case x of ...
         -- This is very important in practice; e.g. wheel-seive1 doubles
         -- in allocation if you miss this out
 }}}
 and
 {{{
         -- Outside a lambda, we want to be reasonably aggressive
         -- about inlining into multiple branches of case
         -- e.g. let x = <non-value>
         --      in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... }
         -- Inlining can be a big win if C3 is the hot-spot, even if
         -- the uses in C1, C2 are not 'interesting'
         -- An example that gets worse if you add int_cxt here is
 'clausify'
 }}}
 At least for the second of these cases, we could do the float-in/inlining
 very late in the compilation pipeline, not all the time.  For the first,
 it's not so clear, but worth experimenting.

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