ACCUMULATE_OUTGOING_ARGS and the i386

[Jeffrey A Law]

  In message < 199810172034.QAA05994@jwlab.FEITH.COM >you write:
  > What are the tradeoffs involved in ACCUMULATE_OUTGOING_ARGS?  Why
  > would I not want to implement it for the i386?  Does it impact debugging?
  > Basically it looks like it could be a good thing, however I want
  > to make sure I'm not being naive. :-)
Plusses:

  Stack pointer stays constant.  So you don't have argument pushes & 
  deallocations.  Stack space is allocated once in the prologue, then
  deallocated in the epilogue.

  A constant stack pointer makes it a lot easier for gdb to grok frame
  pointerless code.  This may make it possible to turn on frame pointer
  elimination by default.

    1. More efficient prologues & epilogues.
    2. The compiler gets to use another register.

  Easier to design correctly functioning ABI which passes args in registers
  (varargs/stdarg is easier to implement).
  

Minuses:

  If the architecture has push insns and they're smaller/faster than
  using reg+d addresses, then ACCUMULATE_OUTGOING_ARGS may be a lose due
  to the increased cost to save arguments into the stack.  Depends on the
  relative costs.


It's something that can definitely be experimented with.  Requires some
hackery to the prologue/epilogue code to get the stack size correct
(have to add in current_function_outgoing_args_size.


jeff