patch to omit the frame pointer from leaf functions (version 2)

[Jeffrey A Law]

  In message < 199810170618.CAA05183@jwlab.FEITH.COM >you write:
  >   1) Both m88k and i386 ports use TARGET_OMIT_LEAF_FRAME_POINTER
  >      to set flag_omit_frame_pointer in OVERRIDE_OPTIONS.  The
  >      name of the macro suggest that the frame pointer is only
  >      to be omitted for leaf functions, yet I'm under the impression
  >      that flag_omit_frame_pointer will attempt to omit the frame
  >      pointer from all functions.  I suspect that this code should
  >      just be deleted.
Check out FRAME_POINTER_REQUIRED for the x86 though.  I'd bet it claims that
a frame pointer is needed for non-leaf functions.

I don't know about the m88k.


  >      In addition, the m88k defines CAN_DEBUG_WITHOUT_FP which
  >      causes flag_omit_frame_pointer to always be set when -O
  >      is specified.  Is this desirable given that fact that the
  >      m88k port also uses TARGET_OMIT_LEAF_FRAME_POINTER?
This would make me suspect TARGET_OMIT_LEAF_FRAME_POINTER for this target
pre-dates automatic frame pointer elimination on that target.  I suspect
that TARGET_OMIT_LEAF_FRAME_POINTER could disappear on the m88k.

  >   2) The i386 port uses flag_omit_frame_pointer in
  >      CONST_DOUBLE_OK_FOR_LETTER_P.  I'm unclear about the issues
  >      involved.
It's in the archives :-)  I actually pointed Bernd to the start of the
thread.  It fixes a relatively obscure, but important bug on the x86.

  >   3) Debugging.  Couple of thoughts:
  > 
  >      a) Update egcs and gdb to use DWARF2 to support debugging
  >         code which has been optimized by this patch.  I'm under
  >         the impression that egcs already outputs the correct
  >         information and that it's just a matter of updating gdb.
  >         I'm not sure about the scope of the work involved.
Likewise.  The code to unwind frames for EH is the same code that the debugger
would need to grok frame pointerless code.  I suspect this is a fair amount of
work, even for the case where the stack pointer is constant.

  >      b) Just update gdb to handle i386 code which has been
  >         optimized in this fashion.  It's not clear to me how
  >         gdb can tell the difference between a frameless function
  >         with an unchanging stack pointer and a frameless function
  >         with a changing stack pointer.
gdb doesn't need to tell the difference.  Debugging frame pointerless code 
doesn't work now.  Basically if you find a function without a frame pointer
you set the base of the frame to whatever value the stack pointer had at entry
to the function.

To compute that you have to look at your current location in the function.  If
you are between the stack pointer adjustments in the prologue/epilogue, then
the base of the frame is $sp - <stack_size>.  Else it is $sp.

Note this has to be fixed in the machine dependent code as far as I know.

  >      What targets (other the i386) are unabled to debug code
  >      which has been optimized by this patch?
h8, m68k, and probably just about every port that does not define
ACCUMULATE_OUTGOING_ARGS.


  > *** gcc/config/pa/pa.c.ORIGINAL	Sun Oct 11 13:57:29 1998
  > --- gcc/config/pa/pa.c	Sat Oct 17 01:05:22 1998
  > *************** basereg_operand (op, mode)
  > *** 5710,5716 ****
  >     /* While it's always safe to index off the frame pointer, it's not
  >        always profitable, particularly when the frame pointer is being
  >        eliminated.  */
  > !   if (! flag_omit_frame_pointer && op == frame_pointer_rtx)
  >       return 1;
  >   
  >     /* The only other valid OPs are pseudo registers with
  > --- 5710,5717 ----
  >     /* While it's always safe to index off the frame pointer, it's not
  >        always profitable, particularly when the frame pointer is being
  >        eliminated.  */
  > !   if (! (flag_omit_frame_pointer || current_function_sp_is_unchanging)
  > !       && op == frame_pointer_rtx)
  >       return 1;
This is undesirable.  The reason we don't allow frame pointers as a base reg
is because we get worse code when the frame pointer is eliminated to the
stack pointer.

jeff