#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