From patchwork Tue Oct 12 11:47:30 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chung-Lin Tang X-Patchwork-Id: 67542 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 1FC76B70A6 for ; Tue, 12 Oct 2010 22:47:34 +1100 (EST) Received: (qmail 13977 invoked by alias); 12 Oct 2010 11:47:31 -0000 Received: (qmail 13963 invoked by uid 22791); 12 Oct 2010 11:47:31 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Oct 2010 11:47:26 +0000 Received: (qmail 30537 invoked from network); 12 Oct 2010 11:47:24 -0000 Received: from unknown (HELO ?59.104.57.187?) (cltang@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Oct 2010 11:47:24 -0000 Message-ID: <4CB44AD2.7090707@codesourcery.com> Date: Tue, 12 Oct 2010 19:47:30 +0800 From: Chung-Lin Tang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Paul Brook CC: gcc-patches@gcc.gnu.org Subject: Re: [patch, ARM] Avoid enlarged alignment when optimizing for size References: <4CA3759B.3080208@codesourcery.com> <201010121110.14620.paul@codesourcery.com> In-Reply-To: <201010121110.14620.paul@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org > I think this comment needs updating. i.e. increasing the alignment tends to > introduce padding, so don't do this when optimizing for size. > > Other than that, ok. > > In theory we could try and be smarter. e.g. still align multiple-of-4 sized > objects, treating readonly/initialized data differently (i.e. where it doesn't > effect runtime init code). In practice I doubt it's worth the hassle, and you > still won't please everyone. Yeah, and here the macros only receive the tree type; does not seem convenient to do that kind of differentiation at this place. Here's the patch with updated comments, I commit it in a few hours unless you feel the wording needs fixing. Thanks, Chung-Lin * config/arm/arm.h (ARM_EXPAND_ALIGNMENT): Rename from DATA_ALIGNMENT and add COND parameter. Update comments above. (DATA_ALIGNMENT): Use ARM_EXPAND_ALIGNMENT, with !optimize_size. (LOCAL_ALIGNMENT): Use ARM_EXPAND_ALIGNMENT, with !flag_conserve_stack. Index: arm.h =================================================================== --- arm.h (revision 165361) +++ arm.h (working copy) @@ -617,15 +617,21 @@ /* Align definitions of arrays, unions and structures so that initializations and copies can be made more efficient. This is not ABI-changing, so it only affects places where we can see the - definition. */ -#define DATA_ALIGNMENT(EXP, ALIGN) \ - ((((ALIGN) < BITS_PER_WORD) \ + definition. Increasing the alignment tends to introduce padding, + so don't do this when optimizing for size/conserving stack space. */ +#define ARM_EXPAND_ALIGNMENT(COND, EXP, ALIGN) \ + (((COND) && ((ALIGN) < BITS_PER_WORD) \ && (TREE_CODE (EXP) == ARRAY_TYPE \ || TREE_CODE (EXP) == UNION_TYPE \ || TREE_CODE (EXP) == RECORD_TYPE)) ? BITS_PER_WORD : (ALIGN)) +/* Align global data. */ +#define DATA_ALIGNMENT(EXP, ALIGN) \ + ARM_EXPAND_ALIGNMENT(!optimize_size, EXP, ALIGN) + /* Similarly, make sure that objects on the stack are sensibly aligned. */ -#define LOCAL_ALIGNMENT(EXP, ALIGN) DATA_ALIGNMENT(EXP, ALIGN) +#define LOCAL_ALIGNMENT(EXP, ALIGN) \ + ARM_EXPAND_ALIGNMENT(!flag_conserve_stack, EXP, ALIGN) /* Setting STRUCTURE_SIZE_BOUNDARY to 32 produces more efficient code, but the value set in previous versions of this toolchain was 8, which pro