David Edelsohn wrote:
Mark Shinwell writes:
Mark> If the hard frame pointer is forced by default, then targets which are
Mark> particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
Mark> Since such targets would presumably not have to force reload to keep
Mark> the frame pointer, then definitions of such macros would not need to
Mark> be side-effecting (in the way described earlier in this thread) and thus
Mark> be satisfactory.
PowerPC also does not need hard_frame_pointer_rtx for all cases.
It seems like a bad idea to force every port to define
INITIAL_FRAME_ADDRESS_RTX to avoid a penalty. Why can't whatever port
needs this change define INITIAL_FRAME_ADDRESS_RTX to
hard_frame_pointer_rtx? One could add "count" to the macro so that the
port can optimize further and avoid hard_frame_pointer_rtx, if possible.
OK, here is what I think is a better suggestion. First note that
expand_builtin_return_addr is used for both __builtin_frame_address and
__builtin_return_address. The behaviour for the return address
case seems to be for target-specific code to override the result of this
function in the case when count == 0; thus, it does indeed not matter what
we return from expand_builtin_return_addr in that case. (I hadn't
realised this before.) The new patch, below, thus has the same behaviour
for __builtin_return_address.
However when dealing with __builtin_frame_address, we must return the
correct value from this function no matter what the value of count. This
patch therefore forces use of a hard FP in such situations.
Is that more satisfactory?
Mark
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
{
