[GHC] #15056: Wrappers inlined too late

[GHC]

#15056: Wrappers inlined too late
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:
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 simonpj):

 The `mate` regression was very delicate.

 In Move.moveDetailsFor, we inline
 {{{
   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!

 (Idea: this aggressive inlining could be done rather late,
 and perhaps be a late float-in pass.  The only gain is less alloc.)

 However, more delicately we end up with this, where `rPA1` is short
 for `rmPieceAt1`:
    $j1 (rPA1 x)  --inline->     let v = rPA1 in ...x...x..
    $j2 (rPA1 x)  --no inline->  $j2 (rPA1 x)
 In the first case `(rPA1 x)` gets `RhsCtxt`, and hence is inlined
 (not boring).  But in the second, the context is boring, so
 not inlined.  Then both these expressions are floated out, but they
 do not get CSEd togehter becuase they look different (one has been
 inlined and the other hasn't).  So then we get
 {{{
    lvl1 = ...x..x..
    lvl2 = rPA1 x
 }}}
 And now the `rPA1 x` is in an `RhsCtxt` and hence is inlined, giving
 two identical expressions.  But it's too late for CSE.  (Indeed,
 CSE is done immediately after float-out, but before any simplification.

 All very delicate, and not the fault of this patch.  Makes me wonder
 if we should should really distinguish between `BoringCtxt` and `RhsCtxt`.
 Idea: just try collapsing them.

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