On 10/02/2010 04:03 PM, H.J. Lu wrote: >> MIN_STACK_BOUNDARY >> (undocumented; local to i386 atm) >> -- appears to be the ABI specified stack boundary, i.e. >> the minimum that must be in place at a call site. This >> somehow differs from I_S_B due to proliferation of >> command-line options. > > It is used to implement -mstackreliagn. I think you should just > move it to i386.c. Otherwise, you have to copy the same logic > to where it is used in i386.c.
Well, the problem here is that there's stuff in i386.c related to enforcing outgoing stack boundary that shouldn't be there. It should be in the generic code where we manage the other bits of the stack boundary code. > On ia32, INCOMING_STACK_BOUNDARY may be different > from PREFERRED_STACK_BOUNDARY. It is used to support > linking against libraries with 4byte incoming stack boundary and > generate 16byte outgoing stack boundary. As an aside let me say that I hate the word "preferred" in this context. It implies that the boundary is optional, and it's not. Second, we're providing too many confusing options to our users. While it's fine for LTO to manage all sorts of differing stack alignment requirements for the functions its compiling, it's not ok for us to expose all that complexity to the user. There should only be the stack boundary as defined by the ABI, plus the increased boundary discovered for local functions and managed by cgraph. I suspect that we have to keep the x86 backend command-line option that adjusts the ABI boundary for backward compatibility with previous gcc versions. > -mdrap is mainly for testing purpose and used in testsuite. > It has caught many bugs. Removing it means regressions > may become latent. That simply means that the set of test cases is incomplete. You get DRAP with highly aligned local variables plus alloca. These same conditions ought to be testable with the code that I'm adding for generic alignment of user variables, but do not use a DRAP register. r~
