From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25885 invoked by alias); 19 Dec 2007 01:58:45 -0000 Received: (qmail 25875 invoked by uid 22791); 19 Dec 2007 01:58:45 -0000 X-Spam-Check-By: sourceware.org Received: from qmta10.westchester.pa.mail.comcast.net (HELO QMTA10.westchester.pa.mail.comcast.net) (76.96.62.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Dec 2007 01:58:37 +0000 Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA10.westchester.pa.mail.comcast.net with comcast id SRAU1Y0050SCNGk5A05E00; Wed, 19 Dec 2007 01:58:35 +0000 Received: from lucon.org ([24.6.230.138]) by OMTA09.westchester.pa.mail.comcast.net with comcast id SRya1Y0032zoa483V00000; Wed, 19 Dec 2007 01:58:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=yU8WktzhKXPtXjgJocYA:9 a=Gk1gKay2ZSqF5o-22dkA:7 a=308P5Dd9szv4J7l_wmvrsR73z74A:4 a=LY0hPdMaydYA:10 Received: by lucon.org (Postfix, from userid 500) id 03383F8251; Tue, 18 Dec 2007 17:58:34 -0800 (PST) Date: Wed, 19 Dec 2007 02:07:00 -0000 From: "H.J. Lu" To: Ross Ridge Cc: gcc@gcc.gnu.org Subject: Re: A proposal to align GCC stack Message-ID: <20071219015833.GA15046@lucon.org> References: <20071218233126.3EA1973D2A@caffeine.csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218233126.3EA1973D2A@caffeine.csclub.uwaterloo.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00552.txt.bz2 On Tue, Dec 18, 2007 at 06:31:26PM -0500, Ross Ridge wrote: > Ross Ridge wrote: > > The -fpreferrred-stack-boundary flag currently generates code that > > assumes the stack aligned to the preferred alignment on function entry. > > If you assume a worse incoming alignment you'll be aligning the stack > > unnecessarily and generating code that this flag doesn't require. > > H.J. Lu writes: > > That is how we get into trouble in the first place. The only place I > > think of where you can guarantee everything is compiled with the same > > -fpreferrred-stack-boundary is kernel. Our proposal will align stack > > only when needed. PREFERRED_STACK_BOUNDARY > ABI_STACK_BOUNDARY will > > generate a largr stack unnecessarily. > > I'm currently using -fpreferred-stack-boundary without any trouble. BTW, it is -mpreferred-stack-boundary. What value did you use for -mpreferred-stack-boundary? The x86 backend defaults to 16byte. The x86-64 psABI specifies 16byte stack alignment. But the ia32 psABI only specifies 4byte stack alignment. That means that the object files generated by gcc may be incompatible with libs or objects compiled by other ia32 psABI confirming compilers. > Your proposal would in fact generate code to align stack when it's not > necessary. This would change the behaviour of -fpreferred-stack-boundary, > hurting performance and that's unacceptable to me. > > >> Ok, if people are using this flag to change the alignment to something > >> smaller than used by the standard ABI, then INCOMING should be > >> MAX(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY). > > > > On x86-64, ABI_STACK_BOUNDARY is 16byte, but the Linux kernel may > > want to use 8 byte for PREFERRED_STACK_BOUNDARY. INCOMING will > > be MIN(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) == 8 byte. A typo, I meant "INCOMING will be MIN(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) == 8". > > Using MAX(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) also equals 8 in that > case and preserves the behaviour -fpreferred-stack-boundary in every case. STACK_BOUNDARY is the minimum stack boundary. MAX(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) == PREFERRED_STACK_BOUNDARY. So the question is if we should assume INCOMING == PREFERRED_STACK_BOUNDARY in all cases: Pros: 1. Keep the current behaviour of -mpreferred-stack-boundary. Cons: 1. The generated code is incompatible with the other object files. I guess we can live with that. H.J.