From patchwork Thu Jun 14 17:16:42 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roland McGrath X-Patchwork-Id: 164974 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 1954F1007D1 for ; Fri, 15 Jun 2012 03:17:07 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1340299028; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:Message-Id:From:To:Subject:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=qtOKnzDLuobG+PIHi0wU7eq+CLA=; b=a6ltNETIR1szyMinhnC2ohaFIkP+YcNtGvwPaBFLrzrIjoCNd166w/0vap//2t Rbw9Cx4pTzFlp4UDbpAlF7g86q7EhdyWSGpWuhvmHZzAXHhBHmwZd1ofqBCkR9Z5 Vpv7fWW7q/vSDTccT1/+X70LSYu4tf/ZNCVafAVPyEEX8= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:X-Google-DKIM-Signature:Received:Received:Received:Date:Message-Id:From:To:Subject:X-Gm-Message-State:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=Dpm3G+S/vK/cX0IKPy6tZdM4XrwYi/5gv+7Z+qCmI+xrWX75jVBVoU5yNpWGAJ P4aYkKmWZ9Hb8C7XDY1OYG0mgIeuyz3By+kQHHs5P5QyWAMHhishVSo0JIoD9TOP LOgzmvW6OVhBy7ywZ+psomsWi9+SPGyCMxTOXDpkxnqoU=; Received: (qmail 19751 invoked by alias); 14 Jun 2012 17:17:00 -0000 Received: (qmail 19738 invoked by uid 22791); 14 Jun 2012 17:16:58 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Jun 2012 17:16:45 +0000 Received: by dalh21 with SMTP id h21so2779502dal.20 for ; Thu, 14 Jun 2012 10:16:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:message-id:from:to:subject:x-windows:x-gm-message-state; bh=/HwLNUs3E/UZBG/wWXFaZrH9MAPzR9O970UU1RZbeuo=; b=FYhJIneTKkRevBHsjXAldx8Tctm0ME5HQ+dYA5JVzUETCm3r0h59V76bkYsCvZlDIl uEQSgV2v/bRZontklcWe7fwve3Kx80O5S9NJPlpwZTPRUmIFJT/XSkApyGjJPq5OKMyo 8x4n6ktWUmFrK9eAIbrmKXCRwwfaEqQOgNVpAUiyRt8K6F5CTAgrPL2qB0AZN4p6rg/H +iYeicff7Af98W/yta7NBYzDBGrJDc34aVZ3isQ4LeXvB73Q46YRatA7P7Wb3YNys54H Q31FwEY9pshHbt/ziFLqqKR/6Jk1KP5ME9xjmOBeXwXb8aYhHPqR56T2qkOa9lSBYFmk RJYQ== Received: by 10.68.225.7 with SMTP id rg7mr655495pbc.21.1339694205187; Thu, 14 Jun 2012 10:16:45 -0700 (PDT) Received: by 10.68.225.7 with SMTP id rg7mr655449pbc.21.1339694204917; Thu, 14 Jun 2012 10:16:44 -0700 (PDT) Received: from frobland.mtv.corp.google.com.google.com ([2620:0:1000:1b01:6631:50ff:fe3b:961a]) by mx.google.com with ESMTPS id z2sm10118539pbv.34.2012.06.14.10.16.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jun 2012 10:16:43 -0700 (PDT) Date: Thu, 14 Jun 2012 10:16:42 -0700 Message-Id: From: Roland McGrath To: gcc-patches@gcc.gnu.org Subject: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore X-Gm-Message-State: ALoCoQkBYQm37Wh7vxszAkXn9qhNBe9WOwCd20s7WXU7DUqby4pxgDeca1EaCZKq/yelIvD0/aKNMJlcfNH6OKP6w+PLgmsk/EI8lzHTFkCCJoybr0bPE/nrM+42bMZpTZwQwNsQRT5tjKDKUVsna0REEJaXygF/OQ== 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 When the ARM compiler needs to ensure the stack pointer stays aligned and it's already doing a multi-register push/pop in the prologue and epilogue, it chooses some arbitrary register to add to the register set in that push and pop just to increase the size of the stack used by 4 bytes. This is presumed to be harmless, since some register that is either call-clobbered or not touched by the function at all is just getting pushed and then the same value popped into it. But if e.g. I use -ffixed-r9 then I think it's a reasonable expectation that no code is generated that touches r9 in any way, shape, or form. (My actual concern is a variant target port still in progress, where the ABI specifies that r9 is reserved, and the system enforces that no instruction may modify r9.) I haven't managed to come up with an isolated test case to demonstrate the bug. Apparently I just don't understand the stack and register pressure requirements that make the compiler get into the situation where it wants to add a random register for alignment padding purposes. I don't have a setup where I can do a proper regression test for ARM. (My system has a /usr/arm-linux-gnueabi/include/ but configuring with --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include did not succeed in building libgcc.) But the change seems pretty obviously correct IMHO. Thanks, Roland gcc/ 2012-06-14 Roland McGrath * config/arm/arm.c (arm_get_frame_offsets): Never use a fixed register as the extra register to save/restore for stack-alignment padding. diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 092e202..bcfef3e 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -16752,7 +16752,12 @@ arm_get_frame_offsets (void) else for (i = 4; i <= (TARGET_THUMB1 ? LAST_LO_REGNUM : 11); i++) { - if ((offsets->saved_regs_mask & (1 << i)) == 0) + /* While the gratuitous register save/restore is ordinarily + harmless, if a register is marked as fixed it may be + entirely forbidden by the system ABI to touch it, so we + should avoid those registers. */ + if (!fixed_regs[i] + && (offsets->saved_regs_mask & (1 << i)) == 0) { reg = i; break;