On Mon, Oct 4, 2010 at 11:27 AM, Richard Henderson <r...@redhat.com> wrote: > 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.
Ia32 is a special case where the incoming/outgoing stack boundary was changed from 4 byte to 16byte. If you want to move that part to generic, you need to define it for generic. >> 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. Change it to OUTGOING_STACK_BOUNDARY. > 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. You need MIN_STACK_BOUNDARY, INCOMING_STACK_BOUNDARY and PREFERRED_STACK_BOUNDARY to support those. >> -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. > As I remembered, -mforce-drap exposed issues with register allocator. ix86_force_drap is only referenced in one place in i386.c. I'd like to keep it. I don't see why it can't be moved to generic. It may expose problems for other targets. Thanks. -- H.J.
