summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/Mips/MipsRegisterInfo.cpp
diff options
context:
space:
mode:
authorJF Bastien <jfb@google.com>2015-07-20 22:51:32 +0000
committerJF Bastien <jfb@google.com>2015-07-20 22:51:32 +0000
commite4d22d59d1db39262790b6afd3521a65be2d7288 (patch)
tree6c5610ddd4acfe80778391c49b9d6daffba5eaab /llvm/lib/Target/Mips/MipsRegisterInfo.cpp
parent87d03450a5a25a75b2c22862ec438ad4d916bd50 (diff)
downloadbcm5719-llvm-e4d22d59d1db39262790b6afd3521a65be2d7288.tar.gz
bcm5719-llvm-e4d22d59d1db39262790b6afd3521a65be2d7288.zip
Targets: commonize some stack realignment code
This patch does the following: * Fix FIXME on `needsStackRealignment`: it is now shared between multiple targets, implemented in `TargetRegisterInfo`, and isn't `virtual` anymore. This will break out-of-tree targets, silently if they used `virtual` and with a build error if they used `override`. * Factor out `canRealignStack` as a `virtual` function on `TargetRegisterInfo`, by default only looks for the `no-realign-stack` function attribute. Multiple targets duplicated the same `needsStackRealignment` code: - Aarch64. - ARM. - Mips almost: had extra `DEBUG` diagnostic, which the default implementation now has. - PowerPC. - WebAssembly. - x86 almost: has an extra `-force-align-stack` option, which the default implementation now has. The default implementation of `needsStackRealignment` used to just return `false`. My current patch changes the behavior by simply using the above shared behavior. This affects: - AMDGPU - BPF - CppBackend - MSP430 - NVPTX - Sparc - SystemZ - XCore - Out-of-tree targets This is a breaking change! `make check` passes. The only implementation of the `virtual` function (besides the slight different in x86) was Hexagon (which did `MF.getFrameInfo()->getMaxAlignment() > 8`), and potentially some out-of-tree targets. Hexagon now uses the default implementation. `needsStackRealignment` was being overwritten in `<Target>GenRegisterInfo.inc`, to return `false` as the default also did. That was odd and is now gone. Reviewers: sunfish Subscribers: aemerson, llvm-commits, jfb Differential Revision: http://reviews.llvm.org/D11160 llvm-svn: 242727
Diffstat (limited to 'llvm/lib/Target/Mips/MipsRegisterInfo.cpp')
-rw-r--r--llvm/lib/Target/Mips/MipsRegisterInfo.cpp49
1 files changed, 10 insertions, 39 deletions
diff --git a/llvm/lib/Target/Mips/MipsRegisterInfo.cpp b/llvm/lib/Target/Mips/MipsRegisterInfo.cpp
index f6647e6a846..775d8006fdf 100644
--- a/llvm/lib/Target/Mips/MipsRegisterInfo.cpp
+++ b/llvm/lib/Target/Mips/MipsRegisterInfo.cpp
@@ -284,6 +284,16 @@ getFrameRegister(const MachineFunction &MF) const {
}
bool MipsRegisterInfo::canRealignStack(const MachineFunction &MF) const {
+ // Avoid realigning functions that explicitly do not want to be realigned.
+ // Normally, we should report an error when a function should be dynamically
+ // realigned but also has the attribute no-realign-stack. Unfortunately,
+ // with this attribute, MachineFrameInfo clamps each new object's alignment
+ // to that of the stack's alignment as specified by the ABI. As a result,
+ // the information of whether we have objects with larger alignment
+ // requirement than the stack's alignment is already lost at this point.
+ if (!TargetRegisterInfo::canRealignStack(MF))
+ return false;
+
const MipsSubtarget &Subtarget = MF.getSubtarget<MipsSubtarget>();
unsigned FP = Subtarget.isGP32bit() ? Mips::FP : Mips::FP_64;
unsigned BP = Subtarget.isGP32bit() ? Mips::S7 : Mips::S7_64;
@@ -306,42 +316,3 @@ bool MipsRegisterInfo::canRealignStack(const MachineFunction &MF) const {
// sized objects.
return MF.getRegInfo().canReserveReg(BP);
}
-
-bool MipsRegisterInfo::needsStackRealignment(const MachineFunction &MF) const {
- const MipsSubtarget &Subtarget = MF.getSubtarget<MipsSubtarget>();
- const MachineFrameInfo *MFI = MF.getFrameInfo();
-
- bool CanRealign = canRealignStack(MF);
-
- // Avoid realigning functions that explicitly do not want to be realigned.
- // Normally, we should report an error when a function should be dynamically
- // realigned but also has the attribute no-realign-stack. Unfortunately,
- // with this attribute, MachineFrameInfo clamps each new object's alignment
- // to that of the stack's alignment as specified by the ABI. As a result,
- // the information of whether we have objects with larger alignment
- // requirement than the stack's alignment is already lost at this point.
- if (MF.getFunction()->hasFnAttribute("no-realign-stack"))
- return false;
-
- const Function *F = MF.getFunction();
- if (F->hasFnAttribute(Attribute::StackAlignment)) {
-#ifdef DEBUG
- if (!CanRealign)
- DEBUG(dbgs() << "It's not possible to realign the stack of the function: "
- << F->getName() << "\n");
-#endif
- return CanRealign;
- }
-
- unsigned StackAlignment = Subtarget.getFrameLowering()->getStackAlignment();
- if (MFI->getMaxAlignment() > StackAlignment) {
-#ifdef DEBUG
- if (!CanRealign)
- DEBUG(dbgs() << "It's not possible to realign the stack of the function: "
- << F->getName() << "\n");
-#endif
- return CanRealign;
- }
-
- return false;
-}
OpenPOWER on IntegriCloud