This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Expansion of __builtin_frame_address


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 
     {

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]