Re: patch to improve i386 epilogue (version 5)

[Jeffrey A Law <law at cygnus dot com>]

  In message <199810090552.BAA15636@jwlab.FEITH.COM>you write:
  > ChangeLog:
  > 
  > Fri Oct  9 01:10:08 EDT 1998  John Wehle  (john@feith.com)
  > 
  > 	* flow.c: Update comment.
  > 	(life_analysis_1): Set current_function_stack_pointer_is_stable.
  > 	* function.c: Define it.
  > 	(init_function_start): Initialize it.
  > 	* output.h: Declare it.
  > 	* i386.c (ix86_epilogue): Optimize the restoring
  > 	of the stack pointer.
  > 

  > + 	  /* If the INSN hasn't been deleted then see if it modifies the
  > + 	     stack pointer.  */
[ ... ]
This code doesn't handle auto-inc addressing modes if they appear in the source
of a set (ie a pop from the stack).   Ah, nevermind, such insns can never
appear before flow (see rtl.texi).  I wonder if we'd be better off calling
note_stores instead of trying to recognize all the cases ourself.

I like the movement away from counting function calls towards determining
if the stack pointer is stable.  Though I think "sp_is_unchanging" may be
a better name for the attribute you're computing.  Obviously if the stack
pointer does not change, then it must be stable :-)

The better name also makes it clear that the function is a prime candidate for
frame pointer elimination.  If you recall, the key reason why we can't kill the
frame pointer is because the stack pointer changes throughout the life of the
function, which makes gdb's life very difficult.

Making gdb handle frame-pointerless code is a lot easier if we know the stack
pointer does not change, except in the prologue/epilogue.  Thus you're a big
step towards being able to eliminate frame pointers in some functions by
default, even if they are not leaf functions.

I don't think it's strictly necessary, but it would probably be wise to 
also mark the stack pointer as live at the end of the function in
mark_regs_live_at_end, fill_simple_delay_slots and dbr_schedule.

jeff