Re: [MinGW-dvlpr] Re: _alloca/_chkstk??

[Christopher F. <cg...@re...>]

On Wed, Oct 08, 2003 at 08:25:35PM +0100, Danny Smith wrote:
>Ranjit, have you discussed your ix86_function_regparm approach
> with Honza, who is assigned the bug (PR12209) 

I'm entering this discussion late but I am confused by some of the
arguments I've seen in this and the gcc list.

To summarize:  The problem is that eax is being clobbered by any
function that does a stack probe.  This impacts functions compiled
using the regparm option or __attribute__ (regparm) or in newer
versions of gcc which optimize argument passing using registers
if -funit-at-a-time is enabled.

There are four potential solutions:

1) save and restore eax around the stack probe call.

Problem: Extra stack operations mean slower code.  This means
that the speed benefit of using regparm is nil or worse although
potential space savings are still there.

2) Use ebx to pass in arguments to a new function which behaves
similarly to chkstk (keeping the old chkstk around for backwards
compatibility).

Problem: While ebx is call saved, this will force ebx to be saved
in times when it might not have to be.

3) Don't use eax for argument passing.  Just use ecx and edx.

Problem: same as 1), AFAICT.  Fewer registers available means
more stack operations.

4) Just push the argument on the stack and let a new chkstk function
get the argument from there.

Problem: the new chkstk function would probably still need to save a
register on stack just to work correctly so as many or more stack
operations would be required.

To me, it seems like the best compromise is 2.  Since there is a good
chance that ebx is going to be saved on the stack anyway, causing it to
be saved in the situation where a stack probe is needed doesn't seem
like much of a hardship.

Am I missing something here?  I'd like to restart this discussion in
the gcc-patches mailing list but I'm checking here first just in
case.

cgf