Ross Ridge wrote:
> I'm currently using -fpreferred-stack-boundary without any trouble.
> Your proposal would in fact generate code to align stack when it's
> not necessary. This would change the behaviour of
> -fpreferred-stack-boundary, hurting performance and that's unacceptable
> to me.
Ye, Joey writes:
> This proposal values correctness at first place. So when compile can't
> make sure a function is only called from functions with the same or bigger
> preferred-stack-boundary, it will conservatively align the stack. One
> optimization is to set INCOMING = PREFERRED for local functions. Do you
> think it more acceptable?
Not really. It might reduce the amount of unnecessary stack adjustment,
but the performance regression would remain. Changing the behaviour of
-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 options.
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 problematic
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. You're
conservatively aligning the incoming stack, but not the outgoing stack.
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 because
"correctness" in this case would cause unacceptable regressions when
compiling the x86_64 Linux kernel.
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.
Ross Ridge
