diff options
author | Roman Tereshin <rtereshin@apple.com> | 2018-10-20 00:06:15 +0000 |
---|---|---|
committer | Roman Tereshin <rtereshin@apple.com> | 2018-10-20 00:06:15 +0000 |
commit | 8d6ff4c0af843e1a61b76d89812aed91e358de34 (patch) | |
tree | 4c37f232d2aabe8250f41e5634276f4e1b0a4fc0 /llvm/lib/CodeGen/MachineCSE.cpp | |
parent | 1fc51f29d7443be52edaf17145a9608368a7154d (diff) | |
download | llvm-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.cpp | 17 |
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); } |