This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Expansion of __builtin_frame_address
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
{