diff options
author | JF Bastien <jfb@google.com> | 2015-07-20 22:51:32 +0000 |
---|---|---|
committer | JF Bastien <jfb@google.com> | 2015-07-20 22:51:32 +0000 |
commit | e4d22d59d1db39262790b6afd3521a65be2d7288 (patch) | |
tree | 6c5610ddd4acfe80778391c49b9d6daffba5eaab /llvm/lib/Target/Mips/MipsRegisterInfo.cpp | |
parent | 87d03450a5a25a75b2c22862ec438ad4d916bd50 (diff) | |
download | bcm5719-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.cpp | 49 |
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; -} |