aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineCSE.cpp
diff options
context:
space:
mode:
authorGuozhi Wei <carrot@google.com>2022-11-14 19:34:59 +0000
committerGuozhi Wei <carrot@google.com>2022-11-14 19:34:59 +0000
commit11e86868c1a1ee67a1d88ef84b68193d06dc996d (patch)
treed7f469322a82228e7efe29067a9a51b70f66055d /llvm/lib/CodeGen/MachineCSE.cpp
parent840a793375fec763c2b2781b82b764325635cc7a (diff)
downloadllvm-11e86868c1a1ee67a1d88ef84b68193d06dc996d.zip
llvm-11e86868c1a1ee67a1d88ef84b68193d06dc996d.tar.gz
llvm-11e86868c1a1ee67a1d88ef84b68193d06dc996d.tar.bz2
[MachineCSE] Allow CSE for instructions with ignorable operands
Ignorable operands don't impact instruction's behavior, we can safely do CSE on the instruction. It is split from D130919. It has big impact to some AMDGPU test cases. For example in atomic_optimizations_raw_buffer.ll, when trying to check if the following instruction can be CSEed %37:vgpr_32 = V_MOV_B32_e32 0, implicit $exec Function isCallerPreservedOrConstPhysReg is called on operand "implicit $exec", this function is implemented as - return TRI.isCallerPreservedPhysReg(Reg, MF) || + return TRI.isCallerPreservedPhysReg(Reg, MF) || TII.isIgnorableUse(MO) || (MRI.reservedRegsFrozen() && MRI.isConstantPhysReg(Reg)); Both TRI.isCallerPreservedPhysReg and MRI.isConstantPhysReg return false on this operand, so isCallerPreservedOrConstPhysReg is also false, it causes LLVM failed to CSE this instruction. With this patch TII.isIgnorableUse returns true for the operand $exec, so isCallerPreservedOrConstPhysReg also returns true, it causes this instruction to be CSEed with previous instruction %14:vgpr_32 = V_MOV_B32_e32 0, implicit $exec So I got different result from here. AMDGPU's implementation of isIgnorableUse is bool SIInstrInfo::isIgnorableUse(const MachineOperand &MO) const { // Any implicit use of exec by VALU is not a real register read. return MO.getReg() == AMDGPU::EXEC && MO.isImplicit() && isVALU(*MO.getParent()) && !resultDependsOnExec(*MO.getParent()); } Since the operand $exec is not a real register read, my understanding is it's reasonable to do CSE on such instructions. Because more instructions are CSEed, so I get less instructions generated for these tests. Differential Revision: https://reviews.llvm.org/D137222
Diffstat (limited to 'llvm/lib/CodeGen/MachineCSE.cpp')
-rw-r--r--llvm/lib/CodeGen/MachineCSE.cpp9
1 files changed, 6 insertions, 3 deletions
diff --git a/llvm/lib/CodeGen/MachineCSE.cpp b/llvm/lib/CodeGen/MachineCSE.cpp
index 3a8c80c..89f4ffc 100644
--- a/llvm/lib/CodeGen/MachineCSE.cpp
+++ b/llvm/lib/CodeGen/MachineCSE.cpp
@@ -265,8 +265,10 @@ bool MachineCSE::isPhysDefTriviallyDead(
}
static bool isCallerPreservedOrConstPhysReg(MCRegister Reg,
+ const MachineOperand &MO,
const MachineFunction &MF,
- const TargetRegisterInfo &TRI) {
+ const TargetRegisterInfo &TRI,
+ const TargetInstrInfo &TII) {
// MachineRegisterInfo::isConstantPhysReg directly called by
// MachineRegisterInfo::isCallerPreservedOrConstPhysReg expects the
// reserved registers to be frozen. That doesn't cause a problem post-ISel as
@@ -275,7 +277,7 @@ static bool isCallerPreservedOrConstPhysReg(MCRegister Reg,
// It does cause issues mid-GlobalISel, however, hence the additional
// reservedRegsFrozen check.
const MachineRegisterInfo &MRI = MF.getRegInfo();
- return TRI.isCallerPreservedPhysReg(Reg, MF) ||
+ return TRI.isCallerPreservedPhysReg(Reg, MF) || TII.isIgnorableUse(MO) ||
(MRI.reservedRegsFrozen() && MRI.isConstantPhysReg(Reg));
}
@@ -298,7 +300,8 @@ bool MachineCSE::hasLivePhysRegDefUses(const MachineInstr *MI,
if (Register::isVirtualRegister(Reg))
continue;
// Reading either caller preserved or constant physregs is ok.
- if (!isCallerPreservedOrConstPhysReg(Reg.asMCReg(), *MI->getMF(), *TRI))
+ if (!isCallerPreservedOrConstPhysReg(Reg.asMCReg(), MO, *MI->getMF(), *TRI,
+ *TII))
for (MCRegAliasIterator AI(Reg, TRI, true); AI.isValid(); ++AI)
PhysRefs.insert(*AI);
}