Skip to content

Potential regression when specializing the linear register allocator

In !4764 we specialized the linear register allocator for the backends to the various instruction data types in the hope of a reasonable performance gain (at the cost of code size naturally).

At first this worked fine

As show in this pipeline https://gitlab.haskell.org/ghc/ghc/-/jobs/634400 for this commit d53ed72b which showed a good number of improvements:

-------------------------
Metric Decrease:
    T12707
    T13379
    T3294
    T4801
    T783
-------------------------

However after rebasing suddenly the results were "strangely two tests regressed while nothing improved" https://gitlab.haskell.org/ghc/ghc/-/jobs/635381

-------------------------
Metric Increase:
    T12707
    T3294
-------------------------

I've bisected the change in behaviour to this commit:

23f4bc89406de24ec77ced45aa267f9a8f8aaa60 is the first bad commit
commit 23f4bc89406de24ec77ced45aa267f9a8f8aaa60
Author: Ben Gamari <ben@smart-cactus.org>
Date:   Tue Dec 22 14:26:43 2020 -0500

    CmmToAsm.Reg.Linear: oneShot-ify RegM

If I cherry-pick 9201bf63 on top of 23f4bc89 it leads to regressions. If I do so for the commit before it, then it improves things.

So somehow this triggers a regression in the specialization.

When compiling compiler/GHC/CmmToAsm/X86.hs with -fspecialize-aggresively we avoid most of the regression. But we still don't see any of the benefits we saw before.

Further on it appears that we fail to specialize one of the linear register allocation methods that has an unfolding. Compiling with -Wall-missed-specialisations should give a hint for anyone looking at that.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information