This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH [i386 windows targets]: Disallow regparm for functions that
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc-patches at gcc dot gnu dot org
- Date: 26 Oct 2003 10:11:00 +0200
- Subject: Re: PATCH [i386 windows targets]: Disallow regparm for functions that
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <3F941106.3040804@ford.com> <3F941106.3040804@ford.com> <20031020214402.GE5033@redhat.com>
cgf@redhat.com (Christopher Faylor) wrote on 20.10.03 in <20031020214402.GE5033@redhat.com>:
> On Mon, Oct 20, 2003 at 12:44:54PM -0400, Kelley Cook wrote:
> >cygwin prologue was clean up). Then I realized that it was no better,
> >and probably worse, than Danny's patch, since the function was doing an
> >extra push/quasi-pop on %eax just to avoid the "penalty" of having to
> >push the parameter onto the stack originally.
>
> I don't see how you can modify __alloca to accomplish this since the
> register is overwritten prior to calling __alloca.
>
> >Which seemed kind of pointless to me.
>
> It's not necessarily pointless. There is still a potential space savings
> in using regparm even if there isn't a speed savings. Since the called
> function often just pushes the arguments on the stack anyway, it is
> not necessarily a loss, if the patch is properly done, either.
Do not forget that it may also be necessary to match the caller's ideas
about the ABI. You don't always control both ends of the interface.
You *can*, of course, work around that by defining an intermediate
function, but surely that solution is worse in all respects?
MfG Kai