forked from OSchip/llvm-project
[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:
parent
c4adc49a1c
commit
3822ac909e
|
@ -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;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue