[PATCH] D70427: [SystemZ] Stop using the Local Area Offset in SystemZFrameLowering.

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

So here is how this is supposed to work, as I understand it.

First of all, on SystemZ, unlike all other platforms, the DWARF CFA (Canonical Frame Address) is not equal to the incoming stack pointer, but to incoming stack pointer plus 160.  This is simply a fact of the SystemZ ABI that we cannot change at this point.

This also affects the definition of the "getOffsetOfLocalArea" value.  While the comment calls this "the offset of the local area from the stack pointer on entrance to a function", we interpret this as "the offset of the local area from the CFA" -- on all other platforms this is equivalent, but for us the difference matters.  Note that since the stack grows downward, this offset describes the number of bytes we have to go **downward** from the CFA in order to reach the **topmost** byte of the local area (which is therefore simply the size of the register save area).

Before register allocation, (fixed) frame objects can be allocated relative to the CFA plus some offset.  This allows reaching incoming arguments (CFA + 0 .. CFA + N) as well as the register save area (CFA ... CFA - 160).  During register allocation, non-fixed frame objects are then allocated to the "local area", i.e. not within the first 160 bytes counting downwards from the CFA.   In a second step, in order to establish addressability during function execution, the address is converted from "CFA - offset" into "SP (or frame pointer in case of variable stack size) + offset".  Note that in that computation, the size of the **other** register save area (which the current function must allocate for its callees) must be included.

Given all that, I believe the SystemZ backend handles this correctly, so I don't think these changes are really necessary.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70427/new/

https://reviews.llvm.org/D70427