aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineCSE.cpp
diff options
context:
space:
mode:
authorRoman Tereshin <rtereshin@apple.com>2018-10-20 00:06:15 +0000
committerRoman Tereshin <rtereshin@apple.com>2018-10-20 00:06:15 +0000
commit8d6ff4c0af843e1a61b76d89812aed91e358de34 (patch)
tree4c37f232d2aabe8250f41e5634276f4e1b0a4fc0 /llvm/lib/CodeGen/MachineCSE.cpp
parent1fc51f29d7443be52edaf17145a9608368a7154d (diff)
downloadllvm-8d6ff4c0af843e1a61b76d89812aed91e358de34.zip
llvm-8d6ff4c0af843e1a61b76d89812aed91e358de34.tar.gz
llvm-8d6ff4c0af843e1a61b76d89812aed91e358de34.tar.bz2
[MachineCSE][GlobalISel] Making sure MachineCSE works mid-GlobalISel (again)
Change of approach, it looks like it's a much better idea to deal with the vregs that have LLTs and reg classes both properly, than trying to avoid creating those across all GlobalISel passes and all targets. The change mostly touches MachineRegisterInfo::constrainRegClass, which is apparently only used by MachineCSE. The changes are NFC for any pipeline but one that contains MachineCSE mid-GlobalISel. NOTE on isCallerPreservedOrConstPhysReg change in MachineCSE: There is no test covering it as the only way to insert a new pass (MachineCSE) from a command line I know of is llc's -run-pass option, which only works with MIR, but MIRParser freezes reserved registers upon MachineFunctions creation, making it impossible to reproduce the state that exposes the issue. Reviwed By: aditya_nandakumar Differential Revision: https://reviews.llvm.org/D53144 llvm-svn: 344822
Diffstat (limited to 'llvm/lib/CodeGen/MachineCSE.cpp')
-rw-r--r--llvm/lib/CodeGen/MachineCSE.cpp17
1 files changed, 16 insertions, 1 deletions
diff --git a/llvm/lib/CodeGen/MachineCSE.cpp b/llvm/lib/CodeGen/MachineCSE.cpp
index dcb6f7c..6ee8571 100644
--- a/llvm/lib/CodeGen/MachineCSE.cpp
+++ b/llvm/lib/CodeGen/MachineCSE.cpp
@@ -235,6 +235,21 @@ MachineCSE::isPhysDefTriviallyDead(unsigned Reg,
return false;
}
+static bool isCallerPreservedOrConstPhysReg(unsigned Reg,
+ const MachineFunction &MF,
+ const TargetRegisterInfo &TRI) {
+ // MachineRegisterInfo::isConstantPhysReg directly called by
+ // MachineRegisterInfo::isCallerPreservedOrConstPhysReg expects the
+ // reserved registers to be frozen. That doesn't cause a problem post-ISel as
+ // most (if not all) targets freeze reserved registers right after ISel.
+ //
+ // It does cause issues mid-GlobalISel, however, hence the additional
+ // reservedRegsFrozen check.
+ const MachineRegisterInfo &MRI = MF.getRegInfo();
+ return TRI.isCallerPreservedPhysReg(Reg, MF) ||
+ (MRI.reservedRegsFrozen() && MRI.isConstantPhysReg(Reg));
+}
+
/// hasLivePhysRegDefUses - Return true if the specified instruction read/write
/// physical registers (except for dead defs of physical registers). It also
/// returns the physical register def by reference if it's the only one and the
@@ -254,7 +269,7 @@ bool MachineCSE::hasLivePhysRegDefUses(const MachineInstr *MI,
if (TargetRegisterInfo::isVirtualRegister(Reg))
continue;
// Reading either caller preserved or constant physregs is ok.
- if (!MRI->isCallerPreservedOrConstPhysReg(Reg))
+ if (!isCallerPreservedOrConstPhysReg(Reg, *MI->getMF(), *TRI))
for (MCRegAliasIterator AI(Reg, TRI, true); AI.isValid(); ++AI)
PhysRefs.insert(*AI);
}