Kenneth Zadeck <Kenneth.Zadeck@NaturalBridge.com> writes:
At the moment, df_get_entry_block_def_set only includes the stack pointer
before prologue and epilogue generation. I don't see any reason for this.
It's true that the incoming rtl stack pointer does have a different meaning
after prologue generation, but its value is still important.
Richard,
The current code assumes that the prologue generation code will
contain some sort of set of the stack pointer. The df code is
conditional on that timing so that some sort of set appears to be
there before the prologue is generated. (In a real compiler, we would
generate the prologue early and we would not be doing any of this
foolishness.) But after the generation of the prologue, the prologue
is supposed to have everything necessary.
Two things:
- The prologue won't set the stack pointer if the function needs no
stack space of its own. But the function can still use the stack
pointer to access incoming arguments.
E.g. imagine a function that takes a lot of arguments, and simply
returns the value of the last one. The optimised version will just
load something relative to the incoming stack pointer, then return.
- My point was that, even if the prologue does allocate stack space,
that set will be of the form:
(set (sp) (plus (sp) (const_int -FOO)))
And since the current DF code says (sp) is uninitialised before the
prologue, the _use_ of (sp) in the instruction above will appear to
be a use of an uninitialised value. I think this is wrong.
That's what I meant when I said that the incoming rtl stack pointer
has a different meaning after prologue generation, but its value is
still important. Before prologue generation, the "incoming" stack
pointer is the value of the stack pointer after stack space has been
allocated. After prologue generation, the "incoming" stack pointer
is the _real_ incoming stack pointer, which the prologue then uses
to allocate any necessary stack space.
Richard