From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2260 invoked by alias); 18 Nov 2011 15:10:59 -0000 Received: (qmail 2251 invoked by uid 22791); 18 Nov 2011 15:10:57 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Nov 2011 15:10:42 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAIFAghB021203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 18 Nov 2011 10:10:42 -0500 Received: from zebedee.pink (ovpn-113-49.phx2.redhat.com [10.3.113.49]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pAIFAfaG001293; Fri, 18 Nov 2011 10:10:41 -0500 Message-ID: <4EC67571.2090600@redhat.com> Date: Fri, 18 Nov 2011 19:35:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Thunderbird/3.1.15 MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: Stack allocation References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00187.txt.bz2 On 11/18/2011 03:03 PM, Alexandru Juncu wrote: > Hello! > > [I sent an email on the gcc main list by my mistake, and I am moving > the discussion here] > > I have a curiosity with something I once tested. I took a simple C > program and made an assembly file with gcc -S. > > The C file looks something like this: > int main(void) > { > int a=1, b=2; > return 0; > } > > The assembly instructions look like this: > > subl $16, %esp > movl $1, -4(%ebp) > movl $2, -8(%ebp) > > The subl $16, means the allocation of local variables on the stack, > right? 16 bytes are enough for 4 32bit integers. > If I have 1,2,3 or 4 local variables declared, you get those 16 bytes. > If I have 5 variables, we have " subl $32, %esp". 5,6,7,8 variables ar > the same. 9, 10,11,12, 48 bytes. > > The observation is that gcc allocates increments of 4 variables (if > they are integers). If I allocate 8bit chars, increments of 16 chars. > > So the allocation is in increments of 16 bytes no matter what. > > OK, that's the observation... my question is why? What's the reason > for this, is it an optimization (does is matter what's the -O used?) > or is it architecture dependent (I ran it on x86) and is this just in > gcc, just in a certain version of gcc or this is universal? > > I got a response that is related to the cache line alignment, to > optimize cache hits. > But I tried to compile the program with the --param l1-cache-size and > got the same .s file. Is this ok? You're not optimizing. Nothing much will happen with optimization options when you're not optimizing. This is x86-specific, but other processors have similar needs. gcc must 16-align the stack because some structures (such as MMX data) must be aligned. Given that the data must be aligned, so must the stack. Also, fetches and stores that straddle cache line boundaries can be very slow. Andrew.