[testcase] ia64 retaddr elimination failure
Geoff Keating
geoffk@geoffk.org
Tue Jan 22 23:49:00 GMT 2002
> 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>
More information about the Gcc
mailing list