This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ppc glibc 2.3 failure
- From: Dale Johannesen <dalej at apple dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Dale Johannesen <dalej at apple dot com>, Aldy Hernandez <aldyh at redhat dot com>, dje at watson dot ibm dot com, gcc at gcc dot gnu dot org
- Date: Mon, 7 Oct 2002 18:09:31 -0700
- Subject: Re: ppc glibc 2.3 failure
On Monday, October 7, 2002, at 05:43 PM, Richard Henderson wrote:
On Mon, Oct 07, 2002 at 04:51:54PM -0700, Dale Johannesen wrote:
Is this the correct solution?
Yes, I think so. I ran into the same problem on Darwin and found
the REG_MAYBE_DEAD notes as a way to identify code added in the
prolog.
I don't think this is right.
Well, it's "right" in the sense that it works. It looks like you want
to add a mechanism so the stack frame computations are remembered rather
than recomputed, when possible. I agree that's more elegant, not to
mention faster; I'll look at it. (The current design is not mine, BTW.)
Basically, the prologue has taken care of the link register.
This is clear from the fact that lr_save_p is false. Thus it is
clear that if the epilogue emits any code to restore lr, that is
a bug. We should not be hiding this bug by marking the prologue
instruction as maybe_dead. It _isn't_ dead. How can the epilogue
restore the link register if it wasn't saved in the prologue?
rs6000_stack_info needs to produce different results when called
during the reload loop (since we might be spilling more and more
registers), but after reload is complete, the values computed
must *never* change.
See ia64_compute_frame_size and how it handles "initialized".