[MCA][RegisterFile] Fix register class check for move elimination (PR50265)

The register file should always check if the destination register is from a
register class that allows move elimination.

Before this change, the check on the register class was only performed in a few
very specific cases. However, it should have always been performed.
This patch fixes the issue.

Note that none of the upstream scheduling models is currently affected by this
bug, so there is no test for it. The issue was found by Roman while working on
the znver3 model. I was able to reproduce the issue locally by tweaking the
btver2 model. I then verified that this patch fixes the issue.
This commit is contained in:
Andrea Di Biagio 2021-05-07 20:20:03 +01:00
parent c4adc49a1c
commit 3822ac909e
1 changed files with 5 additions and 3 deletions

View File

@ -364,6 +364,11 @@ bool RegisterFile::tryEliminateMove(WriteState &WS, ReadState &RS) {
if (RegisterFileIndex != RRITo.IndexPlusCost.first)
return false;
// Early exit if the destination register is from a register class that
// doesn't allow move elimination.
if (!RegisterMappings[RRITo.RenameAs].second.AllowMoveElimination)
return false;
// We only allow move elimination for writes that update a full physical
// register. On X86, move elimination is possible with 32-bit general purpose
// registers because writes to those registers are not partial writes. If a
@ -379,9 +384,6 @@ bool RegisterFile::tryEliminateMove(WriteState &WS, ReadState &RS) {
// that allow move elimination, and how those same registers are renamed in
// hardware.
if (RRITo.RenameAs && RRITo.RenameAs != WS.getRegisterID()) {
// Early exit if the PRF doesn't support move elimination for this register.
if (!RegisterMappings[RRITo.RenameAs].second.AllowMoveElimination)
return false;
if (!WS.clearsSuperRegisters())
return false;
}