Øyvind Harboe wrote:
What I'm wondering about is whether it is possible, in the code that
gets invoked in a "define_insn" to generate the actual assembly, to find
out the difference between the SP and the frame address.
You shoul have asked this the first time.
I'll try to be more specific next time.
What I wrote was a general
case (it should be taken into account from machine-independent code).
For a given architecture the answer could be different. In some APIs,
the difference between sp and fp is always size of local variables and
not changed. You should check API of the target you are interesting in
to get the answer.
Hmmm... I believe I need to make one last go at explaining what I'm
asking about.
The difference between SP & FP is not constant. Take varargs for
instance.
It might be. Please just look at i386 for example (vararg does not
increase frame size or increase it by constant and as consequence it
does not affect changing fp-sp during reload).
This claim should be true regardless of architecture(unless
there is an architecture that does not use stack for varargs, but I
don't think there is). The job of reload1.c/elimination_effects() is to
track such differences as they vary across INSNs.
Reading the documentation on INITIAL_FRAME_POINTER_OFFSET(), I thought
that INITIAL_ELIMINATION_OFFSET() was similarly for immediately after
the function prologue.
Looking at the code in reload1.c, it does look like the elimination
offset tracking information is thrown away after reload.
You could update the offset after each insn as reload does (and store
the change after each insn). Reload is checking that all changes of sp
on control flow paths is the same on joint point. If it is not it does
not make fp elimination.
Rephrasing my question in light of your feedback:
From within a "define_insn" asm generation C code, is there a way to
figure out the difference between the frame pointer and the stack
pointer?
Based upon your feedback so far, I believe the answer is no.
It might be but I am sure for the most targets it is no.
