GitLab

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.

Trac metadata

Trac field	Value
Version	8.2.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture