aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/LockFileManager.cpp
diff options
context:
space:
mode:
authorRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-07-05 12:55:00 +0000
committerRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-07-05 12:55:00 +0000
commit5dd52f8c4da205446a30bb5a7fa1ccb534f45841 (patch)
tree1525aabb4874dfbe6a29152a05405cfa3efbec54 /llvm/lib/Support/LockFileManager.cpp
parent0910ff2cb98ed18320907a8a880ad12d1699801b (diff)
downloadllvm-5dd52f8c4da205446a30bb5a7fa1ccb534f45841.zip
llvm-5dd52f8c4da205446a30bb5a7fa1ccb534f45841.tar.gz
llvm-5dd52f8c4da205446a30bb5a7fa1ccb534f45841.tar.bz2
[SystemZ] Clean up register scavenging code
SystemZ wants normal register scavenging slots, as close to the stack or frame pointer as possible. The only reason it was using custom code was because PrologEpilogInserter assumed an x86-like layout, where the frame pointer is at the opposite end of the frame from the stack pointer. This meant that when frame pointer elimination was disabled, the slots ended up being as close as possible to the incoming stack pointer, which is the opposite of what we want on SystemZ. This patch adds a new knob to say which layout is used and converts SystemZ to use target-independent scavenging slots. It's one of the pieces needed to support frame-to-frame MVCs, where two slots might be required. The ABI requires us to allocate 160 bytes for calls, so one approach would be to use that area as temporary spill space instead. It would need some surgery to make sure that the slot isn't live across a call though. I stuck to the "isFPCloseToIncomingSP - ..." style comment on the "do what the surrounding code does" principle. The FP case is already covered by several Systemz/frame-* tests, which fail without the PrologueEpilogueInserter change, so no new ones are needed. No behavioural change intended. llvm-svn: 185696
Diffstat (limited to 'llvm/lib/Support/LockFileManager.cpp')
0 files changed, 0 insertions, 0 deletions