Ross, HJ, > > >Because I386 PIC requires BX as GOT pointer and I386 may use AX, DX > >and CX as parameter passing registers, there are limited candidates for > >this proposal to choose. Current proposal suggests EDI, because it won't > >conflict with i386 PIC or regparm. > > Could you pick a call-clobbered register in cases where one is availale? I think it is doable. In current Apple engineer's code to support -mstackrealign, hard register ECX is used. We need to add additional code to find which caller save register is not used to pass parameters. If none of them is available, we still have to use callee save reg like EDI.
> > >// Reserve two stack slots and save return address > >// and previous frame pointer into them. By > >// pointing new ebp to them, we build a pseudo > >// stack for unwinding > > Hmmm... I don't know much about the DWARF unwind information, but > couldn't it handle this case without creating the "pseudo frame"? > Or at least be extended so it could? I haven't spent time investigated it yet. I agree it will be much more beautiful without "pseudo frame". I will be happy if solution can be found or be suggested here. But I doubt if it is worthwhile effort. Remember only when stack adjustment + alloca is present, will "pseudo frame" be generated. It may not be so common to impact performance. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of H.J. Lu Sent: 2007年12月18日 13:17 To: Ross Ridge Cc: gcc@gcc.gnu.org Subject: Re: A proposal to align GCC stack On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote: > Ye, Joey writes: > >i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386 > >and 64 for x86_64. It is the minimum stack boundary. It is fixed. > > Strictly speaking by the above definition it would be 8 for i386. > The hardware doesn't force the stack to be 32-bit aligned, it just > performs poorly if it isn't. We can change the wording. > > >v. INCOMING_STACK_BOUNDARY in bits, which is the stack boundary > >at function entry. If a function is marked with __attribute__ > >((force_align_arg_pointer)) or -mstackrealign option is provided, > >INCOMING = STACK_BOUNDARY. Otherwise, INCOMING == MIN(ABI_STACK_BOUNDARY, > >PREFERRED_STACK_BOUNDARY) because a function can be called via psABI > >externally or called locally with PREFERRED_STACK_BOUNDARY. > > This section doesn't make sense to me. The force_align_arg_pointer > attribute and -mstackrealign assume that the ABI is being > followed, while the -fpreferred-stack-boundary option effectively According to Apple engineer who implemented the -mstackrealign, on MacOS/ia32, psABI is 16byte, but -mstackrealign will assume 4byte, which is STACK_BOUNDARY. > changes the ABI. According your defintions, I would think > that INCOMING should be ABI_STACK_BOUNDARY in the first case, > and MAX(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) in the second. That isn't true since some .o files may not be compiled with -fpreferred-stack-boundary or with a different value of -fpreferred-stack-boundary. > (Or just PREFERRED_STACK_BOUNDARY because a boundary less than the ABI's > should be rejected during command line processing.) On x86-64, ABI_STACK_BOUNDARY is 16byte, but the Linux kernel may want to use 8 byte for PREFERRED_STACK_BOUNDARY. > > >vi. REQUIRED_STACK_ALIGNMENT in bits, which is stack alignment required > >by local variables and calling other function. REQUIRED_STACK_ALIGNMENT > >== MAX(LOCAL_STACK_BOUNDARY,PREFERRED_STACK_BOUNDARY) in case of a > >non-leaf function. For a leaf function, REQUIRED_STACK_ALIGNMENT == > >LOCAL_STACK_BOUNDARY. > > Hmm... I think you should define STACK_BOUNDARY as the minimum > alignment that ABI requires the stack pointer to keep at all times. > ABI_STACK_BOUNDARY should be defined as the stack alignment the > ABI requires at function entry. In that case a leaf function's > REQUIRED_STACK_ALIGMENT should be MAX(LOCAL_STACK_BOUNDARY, > STACK_BOUNDARY). That is true since if the only local variable is char, LOCAL_STACK_BOUNDARY will be 1. But we want the stack to be aligned at STACK_BOUNDARY. We will update our proposal. H.J.
