#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