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
