[PATCH] Expansion of __builtin_frame_address

[Ian Lance Taylor]

Mark Shinwell <shinwell@codesourcery.com> writes:

> >> (i) always return the hard frame pointer, and disable FP elimination in
> >> the current function; or
> >>
> >> (iii) ...the same as option (i), but allow targets to define another macro
> >> that will cause the default code to use the soft frame pointer rather than
> >> the hard frame pointer, and hence allow FP elimination.  (If such a macro
> >> were set by a particular target, am I right in thinking that it would be
> >> safe to use the soft frame pointer even in the count >= 1 cases?)
> >
> >> I tend to think that option (iii) might be best, although perhaps it
> >> is overkill and option (i) would do.  But I'm not entirely sure;
> >> still being a gcc novice I have to admit to not being quite thoroughly
> >> clear on this myself at this stage.  So any advice or comments would be
> >> appreciated!
> > I agree that option (iii) is best, as it provides the ability to
> > optimize on platforms where that is feasible, and still provides a
> > working default elsewhere.  I will review and approve a suitable patch
> > to implement (iii), assuming that there are no objections from Jim or
> > others.
> 
> This having been discussed some more, and my understanding improved,
> I now believe that option (i) is in fact the correct thing to do.  The
> attach patch implements this, which basically amounts to the same logic
> that is currently in the compiler save for the removal of the special
> case when count == 0.
> 
> OK for mainline?
> 
> Mark
> 
> --
> 
> 2006-06-01  Mark Shinwell  <shinwell@codesourcery.com>
> 
> 	* gcc/builtins.c (expand_builtin_return_addr): Always use
> 	hard_frame_pointer_rtx and prevent frame pointer elimination
> 	if INITIAL_FRAME_ADDRESS_RTX isn't set.

I also believe this is the correct choice.  This is OK if it passes
bootstrap and testing.

Thanks.

Ian