This question is similar to my last; however, I think it provides a
bit more clarity as to how I am obtaining offsets from the frame
pointer. I have an RTL pass that is processed after expand passes. I
keep track of a list of stack allocated variables. For each VAR_DECL,
I obtain the DECL_RTL rtx. Since these variables are local, the RTL
expression reflects an offset from the stack frame pointer. For
instance, the variable 'matt':
(mem/f/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -8 [0xfffffffffffffff8])) [0 matt+0 S8 A64])
I interpret this as being -8 bytes away from the frame pointer, when
the function 'matt' has scope in is executing. Since 'matt' is a
pointer, and the stack grows downward (x86), and this is a 64-bit
machine, the contents of 'matt' end at the frame pointer and span 8
bytes below the frame pointer to where the first byte of 'matt'
begins. This is fine in some cases, but if I were to rewrite the
source and add a few more variables. It seems that there might be a
few words of padding before the data for the first variable from the
stack pointer begins. If I were to add a 4 byte integer to this
function, 'matt' would still be declared in RTL as above, but instead
of really being -8 it is actually -32. Where do the 24 bytes of
padding between the frame pointer and the last byte of 'matt' come
from? Further, how can I find this initial padding offset at compile
time? I originally thought that the offset in the rtx, as above,
would reflect this stack realignment, but it appears not to.
-Matt
