perhaps this is something known already but I am curious what may be the reason of the current behaviour.
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.