[PATCH] D61437: [AArch64] Static (de)allocation of SVE stack objects.

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

The description of the addressing modes is helpful; I didn't realize there was native support for vl-relative arithmetic.  I guess that makes it more straightforward than I was expecting for stack address computations to skip over the SVE spill slots.

I'm not sure I understand why it's important to allocate the SVE spill slots before the CSRs, as opposed to allocating them between the CSRs and the regular locals/spills.  For code which has a frame pointer, placing the SVE spill slots between the CSRs and the locals/spills has a number of benefits over your suggested layout:

1. the epilogue is cheaper (you don't need an addvl after restoring sp from fp)
2. it's cheaper to access arguments passed on the stack
3. it's cheaper to access the SVE spill slots: you can arrange for the frame pointer to point to the top of the SVE spill area, and use negative offsets from it to spill/restore SVE registers in a single instruction.
4. code using frame pointers can be unwound using a non-SVE-aware DWARF unwinder.

And I don't see any benefits to the other order, unless I'm missing something big.

In cases where we don't have a frame pointer, the two orders are basically equivalent, I guess.

I guess on current SVE implementations, there isn't any advantage to aligning SVE spill slots more than 16 bytes?  And you don't expect that to ever change on future implementations?

I'll write out a diagram for my suggested layout, using a similar style to the one in framelayout-sve.mir, to make sure I'm describing it clearly:

  #     +--------------+
  #     | stack arg    |
  #     +--------------+ <- SP before call
  #     | Callee Saves |
  #     +--------------+
  #     | Frame record |
  #     +--------------+ <- FP
  #     | SVE objs     |
  #     +--------------+
  #     | gap for stack realignment, if there's an over-aligned local variable
  #     +--------------+
  #     |     :        |
  #     | Stack objs   |
  #     |     :        |
  #     +--------------+ <- SP after call and frame-setup



> I don't know enough about the iOS and Windows calling conventions to know if there are explicit assumptions made on the frame-layout other than this?

That's the only relevant restriction, I think, unless you want to count the Windows unwind rules.


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

https://reviews.llvm.org/D61437