llvm dev - Sep 2018 - Scavenging Frame Indices and Stack Alignment

Hi all,

perhaps this is something known already but I am curious what may be the
reason of the current behaviour.

In `PEI::calculateFrameObjectOffsets` in `PrologEpilogInserter.cpp`, the
offsets of the frame indices are determined. Sometimes the backend may have
already registered scavenging frame indices just in case later on the
register scavenger needs to emit spill/reload code.

My understanding after reading the code is that these indices should be
close to the frame pointer (FP) or the stack pointer (SP). This way these
frame indices are easier to refer by the spill/reload code that the
register scavenger may have to emit (here 'easier' means their offsets
are
small and likely to fit in an immediate of an instruction). I'm interested
in the case where we want to allocate them close to the SP (and I'm
thinking on a stack that grows towards lower addresses in case this is
relevant below).

So, when it is determined that the scavenging frame indices have to be
close to the SP, they are allocated offsets after the other objects in
order to guarantee this. However, after that allocation, around line 927,
the stack still has to be aligned so it conforms to the required minimum
alignment of the target or the maximum object allocated. If the backend
does not override `TFI.targetHandlesStackFrameRounding()` the stack is
aligned at this point by increasing the final offset that is used to
compute the stack size.

This means that there may be circumstances in which a frame has a very
strict alignment, say 4096 like it is tested in
`MultiSource/UnitTests/C++11/frame_layout/frame_layout.cpp` of the LLVM
test-suite, and a lot of padding has to be added.

As an example in a RISC-V backend for 64-bit and using the mentioned test,
the scavenging frame index is given an offset SP[-8200] but then the
stacksize is rounded to 12288. For the specific case of RISC-V this means
that the scavenging frame index is already out of range from SP (which is
an offset of 12 bits), if we are to use later the stack size computed at
this point.

It looks to me the final alignment, while required, may unintentionally
defeat the purpose of the scavenging frame indices themselves but perhaps
I'm assigning too much expectation to them in terms of easy access for the
spill/reload code.

I was wondering if it makes sense to compensate the offsets of the
scavenging frame indices so they are still close to the SP. Perhaps this is
a bad idea which can't possibly work in all targets but I admit my
knowledge is not deep enough here to make a sensible judgement.
Alternatively if a target wanted to do these changes we could extend
`TFI.targetHandlesStackFrameRounding()` so it receives the
RegisterScavenger and let the target do some final adjustments.

Kind regards,
-- 
Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180907/c91e2ff7/attachment.html>