This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
It is defined by API. If API requires to allocate stack space for out coming arguments then INITIAL_ELIMINATION_OFFSET should take it into account.Sorry, I don't understand what you mean saying "code-generation in the back-end". As I wrote there is no "FINAL_ELIMINATION_OFFSET" before reload. After the reload it is INITIAL_ELIMINATION_OFFSET.Does something along the lines of a "FINAL_ELIMINATION_OFFSET()" exist, that can be called from code-generation in the back-end?
E.g. INITIAL_ELIMINATION_OFFSET() does not take into account how the stack pointer changes as arguments are pushed onto the stack before a function call.
What I'm wondering about is whether it is possible, in the code thatYou shoul have asked this the first 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.
gets invoked in a "define_insn" to generate the actual assembly, to find
out the difference between the SP and the frame address.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |