This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: recommended alignment for local i386 FP variables patch
- To: John Wehle <john at feith dot com>
- Subject: Re: recommended alignment for local i386 FP variables patch
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 07 Dec 1998 12:07:07 -0700
- cc: jvickers at acorn dot com, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199812042126.QAA04582@jwlab.FEITH.COM>you write:
> > But can have an severe impact as it requires a frame pointer in any
> > function which has a double parameter, and an extra instruction in any
> > function which has a double parameter, even if the stack was already
> > suitably aligned when the function was called.
>
> Not sure what exactly you mean by parameter. If you means local variable
> which doesn't have equivalent memory or constant, then yes. If you simply
> mean an argument to the function, then no. That isn't affected by my appro
> ach.
Opps. I meant "variable" not "parameter". My goof.
> It can be turned on by default if there's already a frame pointer required
> for the function which is currently the case if -fomit-frame-pointer is not
> specified.
True. I hadn't thought of that.
> BTW, I agree that the impact of not being able to reclaim the frame pointer
> is high and yes ... I'm working a little bit against myself considering my
> recent patch to reclaim the frame pointer by default in more cases. :-)
>
> Actually, I'm starting to think more and more that using
> PREFERRED_STACK_ALIGNMENT and defining ACCUMULATE_OUTGOING_ARGS may have
> the best potential for an overall win.
It may be the case that we want more than one scheme for dealing with stack
alignment issues. In large part because there is no clear path :( Both your
patch and my scheme have advantages and disadvantages.
I'll be very curious to hear how the ACCUMULATE_OUTGOING_ARGS stuff works out.
I've heard conflicting information on the effects of this code generation
strategy for the x86. Particularly lossages because we use reg+d instructions
to store args instead of pushing them. But if ACCUMULATE_OUTGOING_ARGS proves
profitable, many of the alignment issues become much easier to solve.
jeff