aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/Sparc/SparcFrameLowering.cpp
diff options
context:
space:
mode:
authorJames Y Knight <jyknight@google.com>2015-08-26 17:57:51 +0000
committerJames Y Knight <jyknight@google.com>2015-08-26 17:57:51 +0000
commit360228693758b6735926a1c77a7f0830cd0c3034 (patch)
tree813e8fbbd5a6996b82a3df98f7d391ef8974e8ab /llvm/lib/Target/Sparc/SparcFrameLowering.cpp
parentc9e544429ab64608c0bcfd884de92b77fd94dda1 (diff)
downloadllvm-360228693758b6735926a1c77a7f0830cd0c3034.zip
llvm-360228693758b6735926a1c77a7f0830cd0c3034.tar.gz
llvm-360228693758b6735926a1c77a7f0830cd0c3034.tar.bz2
[SPARC] Fix stupid oversight in stack realignment support.
If you're going to realign %sp to get object alignment properly (which the code does), and stack offsets and alignments are calculated going down from %fp (which they are), then the total stack size had better be a multiple of the alignment. LLVM did indeed ensure that. And then, after aligning, the sparc frame code added 96 (for sparcv8) to the frame size, making any requested alignment of 64-bytes or higher *guaranteed* to be misaligned. The test case added with r245668 even tests this exact scenario, and asserted the incorrect behavior, which I somehow failed to notice. D'oh. This change fixes the frame lowering code to align the stack size *after* adding the spill area, instead. Differential Revision: http://reviews.llvm.org/D12349 llvm-svn: 246042
Diffstat (limited to 'llvm/lib/Target/Sparc/SparcFrameLowering.cpp')
-rw-r--r--llvm/lib/Target/Sparc/SparcFrameLowering.cpp31
1 files changed, 30 insertions, 1 deletions
diff --git a/llvm/lib/Target/Sparc/SparcFrameLowering.cpp b/llvm/lib/Target/Sparc/SparcFrameLowering.cpp
index 5ce51cf..b924509 100644
--- a/llvm/lib/Target/Sparc/SparcFrameLowering.cpp
+++ b/llvm/lib/Target/Sparc/SparcFrameLowering.cpp
@@ -118,8 +118,37 @@ void SparcFrameLowering::emitPrologue(MachineFunction &MF,
SAVErr = SP::ADDrr;
}
+ // The SPARC ABI is a bit odd in that it requires a reserved 92-byte
+ // (128 in v9) area in the user's stack, starting at %sp. Thus, the
+ // first part of the stack that can actually be used is located at
+ // %sp + 92.
+ //
+ // We therefore need to add that offset to the total stack size
+ // after all the stack objects are placed by
+ // PrologEpilogInserter calculateFrameObjectOffsets. However, since the stack needs to be
+ // aligned *after* the extra size is added, we need to disable
+ // calculateFrameObjectOffsets's built-in stack alignment, by having
+ // targetHandlesStackFrameRounding return true.
+
+
+ // Add the extra call frame stack size, if needed. (This is the same
+ // code as in PrologEpilogInserter, but also gets disabled by
+ // targetHandlesStackFrameRounding)
+ if (MFI->adjustsStack() && hasReservedCallFrame(MF))
+ NumBytes += MFI->getMaxCallFrameSize();
+
+ // Adds the SPARC subtarget-specific spill area to the stack
+ // size. Also ensures target-required alignment.
NumBytes = MF.getSubtarget<SparcSubtarget>().getAdjustedFrameSize(NumBytes);
- MFI->setStackSize(NumBytes); // Update stack size with corrected value.
+
+ // Finally, ensure that the size is sufficiently aligned for the
+ // data on the stack.
+ if (MFI->getMaxAlignment() > 0) {
+ NumBytes = RoundUpToAlignment(NumBytes, MFI->getMaxAlignment());
+ }
+
+ // Update stack size with corrected value.
+ MFI->setStackSize(NumBytes);
emitSPAdjustment(MF, MBB, MBBI, -NumBytes, SAVErr, SAVEri);