This is the mail archive of the
mailing list for the GCC project.
RE: A proposal to align GCC stack
- From: "Ye, Joey" <joey dot ye at intel dot com>
- To: "Ross Ridge" <rridge at csclub dot uwaterloo dot ca>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Thu, 20 Dec 2007 16:49:52 +0800
- Subject: RE: A proposal to align GCC stack
- References: <20071219031617.02C7073CC4@caffeine.csclub.uwaterloo.ca>
Ye, Joey writes:
>> This proposal values correctness at first place. So when compile
>> make sure a function is only called from functions with the same or
>> preferred-stack-boundary, it will conservatively align the stack. One
>> optimization is to set INCOMING = PREFERRED for local functions. Do
>> think it more acceptable?
Ross Ridge wrote:
> Not really. It might reduce the amount of unnecessary stack
> but the performance regression would remain. Changing the behaviour
> -fpreferred-stack-boundary doesn't make it more correct. It supposed
> to change the ABI, it works as documented and, yes, if it's misused it
> will cause problems. So will any number of GCC's ABI changing
> Look at it another way. Lets say you were compiling x86_64 code with
> -fpreferred-stack-boundary=3, an 8-byte PREFERRED alignment. As you
> know, this is different from the standard x86_64 ABI which requires a
> 16-byte alignment. Now with your proposal, GCC's behaviour of won't
> change, because it's safe to assume that incoming stack is at least
> 8-byte aligned. There should be no change in the code GCC generates,
> with or without your proposal. However, the outgoing stack won't be
> 16-byte aligned as the x86_64 ABI requires. In this case, what also
> doesn't change is the fact that mixing code compiled with different
> -fpreferred-stack-boundary values doesn't work. It's just as
> and unsafe as it was before.
> So when you said "this proposal values correctness at first place",
> that really isn't true. The proposal only addresses safety when
> preferred alignment is raised from the standard ABI's alignment.
> conservatively aligning the incoming stack, but not the outgoing
> You don't seem to be concerned about the problems that can arise when
> the preferred is raised above the ABI's. Why? My guess is that
> "correctness" in this case would cause unacceptable regressions when
> compiling the x86_64 Linux kernel.
You are right. My proposal doesn't guarantee 100% correctness. In case
of PREFERRED < ABI, we hope the author knows what will happen.
> If you can understand why it would be unacceptable to change how
> -fpreferred-stack-boundary behaves when compiling the Linux kernel,
> then maybe you can understand why I don't find it acceptable for it to
> change when compiling my code.
I think I understand now. My updated version proposal sets
INCOMING == PREFERRED, and -fpreferred-stack-boundary works
the same as before.
Thanks - Joey