RE: A proposal to align GCC stack

["Ye, Joey" <joey dot ye at intel dot com>]

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?

Ross Ridge wrote:
> 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.
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