-fomit-frame-pointer interaction with alloca - egcs-1.0.1

[Jeffrey A Law]

  In message < 01BD3541.A9DE33A0@malvinas.AtlanTech.COM >you write:
  > Carr>  /* If I3 has an inc, then give up if I1 or I2 uses the reg that is i
  > nc'd.
  > Carr>     We used to do this EXCEPT in one case: I3 has a post-inc in an
  > Carr>     output operand.  However, that exception can give rise to insns l
  > ike
  > Carr>     	mov r3,(r3)+
  > Carr>     which is a famous insn on the PDP-11 where the value of r3 used a
  > s the
  > Carr>     source was model-dependent.  Avoid this sort of thing.  */
  > Carr> I think implementations of the 8086 architecture also disagreed on th
  > e
  > Carr> meaning of push %sp.
  > 
  > Good, that tells me why egcs *DOESN'T* generate "push %esp".  Now could you
  > tell me why egcs *DOES* generate "push %esp"?  Consistency may be the
  > hobgoblin of petty minds*, but this is silly.
  > 
  > >From the part of my message not quoted you can see that egcs generates the
  > "push %esp" instruction when it feels like it.
It gets created by CSE.  I don't see any code in CSE to avoid this
situation.

So my question is what exactly does push %esp do on modern x86 machines?
(or more correctly an x86 machine that gcc can compile code for -- 8086
does not count :-)

There was talk about 6 years ago of either removing this particular
restriction from combine, or conditionalizing it so that ports where
such insns have well defined behavior could use such insns.

jeff