This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH commited to dataflow branch.
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, David Edelsohn <dje at watson dot ibm dot com>, gcc patches <gcc-patches at gcc dot gnu dot org>, Berlin Daniel <dberlin at dberlin dot org>
- Date: Thu, 06 Jul 2006 14:29:13 +0100
- Subject: Re: PATCH commited to dataflow branch.
- References: <200607051749.k65Hns9s026319@d12av02.megacenter.de.ibm.com> <44AC7B85.5090002@naturalbridge.com>
I've not been following this discussion in all its technical detail, but
there's an issue here that I think is worth highlighting in case it's
been overlooked.
Register elimination can sometimes eliminate a 'frame' register into a
use of the stack pointer. While it is normally perfectly acceptable to
auto-modify a frame register (it's just a pointer into the stack), this
is not generally true of the stack pointer. While it is a pointer into
the stack it is also much more than that: it indicates the extent of the
stack allocated, so an auto-modify memory access not only loads/stores a
value, but it also allocates, or frees some stack space. In some
operating environments the run-time system may use any unallocated part
of the stack for its own nefarious purposes. So for example:
(set x (mem:si (post_inc(sp)))
(nop)
(set y (mem:SI (pre_dec(sp)))
does not necessarily set y to the same value as x. Yet the above
sequence would be perfectly safe if we substitute FP for SP.
R.