[PATCH] Expansion of __builtin_frame_address

[Mark Shinwell]

Ian Lance Taylor wrote:
> 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.

I'm sorry to prolong this thread, but I think the patch below is
more satisfactory, since it doesn't force a frame pointer for
__builtin_return_address in the count == 0 case (in such cases we
don't need to force the FP since target-specific code does the
correct thing at a later stage).

This of course is still not entirely satisfactory from the point of
view of __builtin_frame_address, since we can't just stroll up the
frames on some targets.  To try to tighten the behaviour here, it has
been suggested that the target-specific macro CAN_DEBUG_WITHOUT_FP
could be used.  If this is defined, we might suspect that the stack
doesn't have a regular layout, and therefore make __builtin_frame_address
cause a static error for n > 0.  This might be overkill, however, given
how much of a can of worms this general area is.

Mark

--

2006-06-07  Mark Shinwell  <shinwell@codesourcery.com>

	* gcc/builtins.c (expand_builtin_return_addr): Only use
	frame_pointer_rtx when count == 0 and we are expanding
	__builtin_return_address.

--

Index: builtins.c
===================================================================
--- builtins.c	(revision 114325)
+++ builtins.c	(working copy)
@@ -496,12 +496,16 @@ expand_builtin_return_addr (enum built_i
  #else
    rtx tem;

-  /* For a zero count, we don't care what frame address we return, so frame
-     pointer elimination is OK, and using the soft frame pointer is OK.
-     For a non-zero count, we require a stable offset from the current frame
-     pointer to the previous one, so we must use the hard frame pointer, and
+  /* For a zero count with __builtin_return_address, we don't care what
+     frame address we return, because target-specific definitions will
+     override us.  Therefore frame pointer elimination is OK, and using
+     the soft frame pointer is OK.
+
+     For a non-zero count, or a zero count with __builtin_frame_address,
+     we require a stable offset from the current frame pointer to the
+     previous one, so we must use the hard frame pointer, and
       we must disable frame pointer elimination.  */
-  if (count == 0)
+  if (count == 0 && fndecl_code == BUILT_IN_RETURN_ADDRESS)
      tem = frame_pointer_rtx;
    else
      {