From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23073 invoked by alias); 18 Dec 2007 15:06:43 -0000 Received: (qmail 23064 invoked by uid 22791); 18 Dec 2007 15:06:42 -0000 X-Spam-Check-By: sourceware.org Received: from qmta03.emeryville.ca.mail.comcast.net (HELO QMTA03.emeryville.ca.mail.comcast.net) (76.96.30.32) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Dec 2007 15:06:29 +0000 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id SBPW1Y0030FhH240A0DU00; Tue, 18 Dec 2007 15:06:33 +0000 Received: from lucon.org ([24.6.230.138]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id SF6Y1Y00F2zoa488U00000; Tue, 18 Dec 2007 15:06:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=RW4dTeuLRB-7YrApfEUA:9 a=0Vo52W7ADVQwPwSHSWcA:7 a=KnfTTQVUsUpQ5fltPkhQYZZIMhoA:4 a=LY0hPdMaydYA:10 Received: by lucon.org (Postfix, from userid 500) id EB207F8251; Tue, 18 Dec 2007 07:06:26 -0800 (PST) Date: Tue, 18 Dec 2007 16:14:00 -0000 From: "H.J. Lu" To: Ross Ridge Cc: gcc@gcc.gnu.org Subject: Re: A proposal to align GCC stack Message-ID: <20071218150626.GA12651@lucon.org> References: <20071218083942.78BA073CC4@caffeine.csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218083942.78BA073CC4@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/msg00523.txt.bz2 On Tue, Dec 18, 2007 at 03:39:42AM -0500, Ross Ridge wrote: > >> 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. > > Like with any ABI changing flag, that's not supported: > > ... Further, every function must be generated such that it keeps > the stack aligned. Thus calling a function compiled with a higher > preferred stack boundary from a function compiled with a lower > preferred stack boundary will most likely misalign the stack. > > 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. 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. We have considered adding a new option, -fincoming-stack-boundary. But we need to consider local/global functions as well as function pointers. If a function can only be called locally, its incoming stack boundary will be PREFERRED_STACK_BOUNDARY. Otherwise, its incoming stack boundary will be MIN(INCOMING_STACK_BOUNDARY, INCOMING_STACK_BOUNDARY,PREFERRED_STACK_BOUNDARY). We aren't sure if its benefit will be worth its complexity. > > > On x86-64, ABI_STACK_BOUNDARY is 16byte, but the Linux kernel may > > want to use 8 byte for PREFERRED_STACK_BOUNDARY. > > 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. H.J.