[SystemZ] Clean up register scavenging code
authorRichard Sandiford <rsandifo@linux.vnet.ibm.com>
Fri, 5 Jul 2013 12:55:00 +0000 (12:55 +0000)
committerRichard Sandiford <rsandifo@linux.vnet.ibm.com>
Fri, 5 Jul 2013 12:55:00 +0000 (12:55 +0000)
commit7271ac2c0318043688ddc8686dd23777dca62c59
treee251b6a1463e2a77ec8c224dacc7fdd1428a9fa5
parentef2703a1fbe6f7f2aed9bbb8f501a4b0d068886e
[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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185696 91177308-0d34-0410-b5e6-96231b3b80d8
include/llvm/Target/TargetFrameLowering.h
lib/CodeGen/PrologEpilogInserter.cpp
lib/Target/SystemZ/SystemZFrameLowering.cpp
lib/Target/SystemZ/SystemZFrameLowering.h
lib/Target/SystemZ/SystemZRegisterInfo.cpp
lib/Target/SystemZ/SystemZRegisterInfo.h