[PATCH] D70427: [SystemZ] The Local Area Offset in SystemZFrameLowering.

Ulrich Weigand via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 20 08:43:49 PST 2019


uweigand added a comment.

In D70427#1753150 <https://reviews.llvm.org/D70427#1753150>, @jonpa wrote:

> The one part that stands out from this then to me, is the fact that the SpillOffsetTable is relative to the incoming SP, which is why the offsets are incorrect in the created stack objects. To have a fully correct IR, I guess we should return offsets relative to the CFA, in other words subtract 160 from each entry. But there is no real point in this since those offsets are never used (we compute the offset for the STMG instead), so I instead figured that at least having a comment mentioning that might be helpful.


Hmm, this may actually be simple to fix, have the SpillOffsetTable (which is used by common code) use offsets relative to the CFA, and convert it to offset relative to incoming SP when filling RegSpillOffsets (which is used by the SystemZ code).  If this reduces confusion when reading MI dumps, this may be worthwhile to do.

> Unfortunately I was still left with a slight confusion, as I am not quite sure how this works for the FPRs part of that table: Normally those FPRs are not callee-saved, so it wouldn't matter. But how about the CSR_SystemZ_AllRegs calling convention? If F0D would be callee-saved, would it end up in the right place?

F0D, F2D, F4D, F6D are used for passing floating-point arguments and must be saved into those specific slots in a function that uses variable argument lists, since the va_list holds a pointer to the start of the register save area, and va_arg assumes the first four floating-point arguments are stored at those particular offsets relative to that pointer.  If you use AllRegs, they'll also be saved there, which isn't really required, but doesn't hurt either.  Any other register, whether the normal call-saved register, or the other call-clobbered ones when using AllRegs, do not have assigned slots and will be saved in some arbitrary place on the stack allocated during register allocation.


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

https://reviews.llvm.org/D70427





More information about the llvm-commits mailing list