[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