From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26639 invoked by alias); 19 Dec 2007 01:21:05 -0000 Received: (qmail 26286 invoked by uid 22791); 19 Dec 2007 01:21:04 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Dec 2007 01:20:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C48AF2A9654; Tue, 18 Dec 2007 20:20:56 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xhg3YAD2jFdY; Tue, 18 Dec 2007 20:20:56 -0500 (EST) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id 572F72A9656; Tue, 18 Dec 2007 20:20:56 -0500 (EST) Message-ID: <476871ED.1070601@adacore.com> Date: Wed, 19 Dec 2007 01:25:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ross Ridge CC: gcc@gcc.gnu.org Subject: Re: A proposal to align GCC stack References: <20071218233125.5586173D25@caffeine.csclub.uwaterloo.ca> In-Reply-To: <20071218233125.5586173D25@caffeine.csclub.uwaterloo.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00546.txt.bz2 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. > > Ross Ridge wrote: >> 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. > > Robert Dewar writes: >> First, although for some types, the accesses may work, the optimizer >> is allowed to assume that data is properly aligned, and could possibly >> generate incorrect code ... > > That's not enforced by hardware. But suppose we have something like int(&k) & 1. The optimizer is permitted to replace this with 0 if it knows that the type of k is four byte aligned. > >> Second, I am pretty sure there are SSE types that require >> alignment at the hardware levell, even on the i386 > > This isn't a restriction on stack aligment. It's a restriction on what > kinds of machine types can be accessed on the stack. Well if we have local variables of type float (and we have specified use of SSE), we are in trouble, no? > This is different than the proposed ABI_STACK_BOUNDARY macro which defines > the possibily stricter aligment the ABI requires at function entry. Since > most i386 ABIs don't require a stricter alignment, that has ment that > SSE types couldn't be located on the stack. Currently you can get around > this problem by changing the ABI using -fperferred-stack-boundary or by > forcing an SSE compatible alignment using -mstackrealign or __attribute__ > ((force_align_arg_pointer)). Joey Ye's proposal is another solution > to this problem where GCC would automatically force an SSE compatible > aligment when SSE types are used on the stack. right ... > > Ross Ridge