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.