This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [testcase] ia64 retaddr elimination failure
- From: Geoff Keating <geoffk at geoffk dot org>
- To: rth at redhat dot com
- Cc: gcc at gcc dot gnu dot org, jakub at redhat dot com, wilson at cygnus dot com
- Date: Tue, 22 Jan 2002 16:41:35 -0800
- Subject: Re: [testcase] ia64 retaddr elimination failure
- References: <200201222122.g0MLMfV04281@desire.geoffk.org> <20020122133050.A20518@redhat.com>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
> Date: Tue, 22 Jan 2002 13:30:50 -0800
> From: Richard Henderson <rth@redhat.com>
> Cc: gcc@gcc.gnu.org, jakub@redhat.com, wilson@cygnus.com
> On Tue, Jan 22, 2002 at 01:22:41PM -0800, Geoff Keating wrote:
> > Actually, what I expected is that if the routine has no frame pointer,
> > then __builtin_frame_pointer(0) should either (a) fail, or (b) return
> > the stack pointer which is what the frame pointer got eliminated to,
> > and which is what we're actually accessing the frame with. I think
> > (b) is nicer.
>
> I see no reason why __builtin_frame_pointer(0) doesn't just
> return frame_pointer_rtx rather than the hard frame pointer.
Well, it is documented as
If the processor has a dedicated frame pointer register, and the
function has a frame, then `__builtin_frame_address' will return
the value of the frame pointer register.
which is not necessarily the same thing as frame_pointer_rtx, there
will often be some kind of offset.
I guess the only place the difference would matter is when trying to
compute frame_pointer_rtx for a parent function, so you can compare
__builtin_frame_pointer(0) with __builtin_frame_pointer(n) for n>=1;
but then again, __builtin_frame_pointer(n) doesn't work for lots of
other reasons and it's likely that when it does work,
frame_pointer_rtx and hard_frame_pointer_rtx differ in some simple way
and so you can get the right frame pointer from the stack contents
anyway.
> Personally I think any mention of the hard frame pointer
> before reload is dodgy at best, since we don't know if it
> really exists or not.
I agree.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>