This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ACCUMULATE_OUTGOING_ARGS and the i386
- To: Joe Buck <jbuck at synopsys dot com>
- Subject: Re: ACCUMULATE_OUTGOING_ARGS and the i386
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 18 Oct 1998 23:54:38 -0600
- cc: john at feith dot com, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199810190547.WAA27970@atrus.synopsys.com>you write:
> It seems that #2 would be a big win on the register-poor i386
> architecture. Also, overhead for C++ exceptions should be reduced
> substantially, right?
Yes. The extra reg is a big help. As is eliminating all the argument pops.
When I switched the mn103 to use ACCUMULATE_OUTGOING_ARGS codesize dropped by
about 10%. Due to some braindamage in the architecture that number probably
is more than any other processor will achieve. But you get the idea.
Note that the mn103 does not push args. So the cost to store args is the
same with both schemes. There was no way it could lose :-)
I'm not an EH expert, but I would expect both the cost in frame descriptors to
be reduced and the unwinding code itself should be a lot simpler since the
number of states the stack pointer can be in is much smaller.
> > 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.
>
> Given the other factors, this increased cost might be outweighed by
> the benefits, but of course this would have to be measured. I suspect
> that a push might even be slower on the new processors if there are
> many separate stack adjustments, but I'm far from an x86 guru.
Definitely needs measurement for any target where one wants to enable it.
jeff