From patchwork Tue Jul 10 06:09:55 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 170052 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 E77F72C0350 for ; Tue, 10 Jul 2012 16:10:26 +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=1342505427; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:MIME-Version:Content-Type:Content-Disposition: User-Agent:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=y75zbDQ QEY49ov8BDry/oPPeMBQ=; b=EZpbLL4dHIzoTkvJWEyh6NsYG57dnsnSKID1MpJ Gb4S3DZaX0e1erCopDEQaicPuhCH0Oms7EgPNFLLUmT5kUGy0pXyeg3N5VGQb1CS Gfs5v8mUM0jmssMGVnuATnBgQZWUJ00hwnoDTrrawRSwWxpmILC6uH67yiolMa/1 HwiY= 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:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ETtwoSk47U/h8Qy5uw6fW5M+YoYf5cjXpEAKOQD5NuWJW0FrpRFuuP5If7ybRI 8kJXyUhg/clX6zj4/rglHxHDuNjtLJoluhqo06qsgq9xKcp2ko7RhjI3hf8DDt66 Im/5FyEPzDj8a4JzbecGEPJRAOYdEPc+58Bg+c0GYzVtg=; Received: (qmail 25631 invoked by alias); 10 Jul 2012 06:10:18 -0000 Received: (qmail 25619 invoked by uid 22791); 10 Jul 2012 06:10:16 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-pb0-f47.google.com (HELO mail-pb0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Jul 2012 06:10:02 +0000 Received: by pbbrq2 with SMTP id rq2so20723393pbb.20 for ; Mon, 09 Jul 2012 23:10:01 -0700 (PDT) Received: by 10.68.200.104 with SMTP id jr8mr35390556pbc.9.1341900601585; Mon, 09 Jul 2012 23:10:01 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id to1sm29237023pbc.27.2012.07.09.23.09.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 23:10:00 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 5A67AEA0428; Tue, 10 Jul 2012 15:39:55 +0930 (CST) Date: Tue, 10 Jul 2012 15:39:55 +0930 From: Alan Modra To: David Edelsohn Cc: gcc-patches@gcc.gnu.org, Michael Meissner , Peter Bergner Subject: [RS6000] offset addressing Message-ID: <20120710060955.GC3117@bubble.grove.modra.org> Mail-Followup-To: David Edelsohn , gcc-patches@gcc.gnu.org, Michael Meissner , Peter Bergner MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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 Hi David, I've been auditing rs6000.c after looking at https://bugzilla.redhat.com/show_bug.cgi?id=837630 We have problems all over the place. :-( For starters, this code in rs6000_legitimate_offset_address_p. case TFmode: ... case TDmode: case TImode: if (mode == TFmode || mode == TDmode || !TARGET_POWERPC64) extra = 12; else if (offset & 3) return false; else extra = 8; break; Notice how a TFmode when TARGET_POWERPC64 gets extra==12. How can that be corrent? Both general and floating point registers are 8 bytes. However, this is not the main problem I see here and in many other places. The problem is that the mode is only a hint as to the register used in the insn. You can easily have a floating point mode in gprs or an integer mode in fprs, as shown by the following examples. These are all quite contrived, but a similar situation may arise in real code due to register pressure. double a, b; void f1 (void) { double tmp = a; asm ("#" : "+r" (tmp) : : "fr0", "fr1", "fr2","fr3", "fr4", "fr5", "fr6", "fr7", "fr8", "fr9", "fr10", "fr11", "fr12", "fr13", "fr14", "fr15", "fr16", "fr17", "fr18", "fr19", "fr20", "fr21", "fr22", "fr23", "fr24", "fr25", "fr26", "fr27", "fr28", "fr29", "fr30", "fr31"); b = tmp; } long long x, y; void f2 (void) { long long tmp = x; asm ("#" : "+f" (tmp) : : "r0", "r1", "r2","r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15", "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23", "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31"); y = tmp; } long double la, lb; void f3 (void) { long double tmp = la; asm ("#" : "+r" (tmp) : : "fr0", "fr1", "fr2","fr3", "fr4", "fr5", "fr6", "fr7", "fr8", "fr9", "fr10", "fr11", "fr12", "fr13", "fr14", "fr15", "fr16", "fr17", "fr18", "fr19", "fr20", "fr21", "fr22", "fr23", "fr24", "fr25", "fr26", "fr27", "fr28", "fr29", "fr30", "fr31"); lb = tmp; } So I think that rs6000_legitimate_offset_address_p code snippet ought to be case TFmode: ... case TDmode: case TImode: if (!TARGET_POWERPC64) extra = 12; else if (offset & 3) return false; else extra = 8; break; We can't assume that TFmode or TDmode are in fprs, so for 32-bit that means a possible addition of 12 to the offset and for 64-bit it means the offset must be a multiple of 4. If I go ahead and fix the many places in rs6000.c we will see some code degradation for oddball cases. For example, loading a mis-aligned double (well, not 4-byte aligned) on ppc64 to a fpr will use direct addressing rather than offset addressing. Maybe we could do something about that with a peephole.. I know the above isn't anything new. When this sort of problem came up in the past we didn't want to lose code quality in the common case, and tried to avoid the correctness issue with hacks that made incorrect code unlikely to occur. The thing is that with section anchors we are much more likely to see offset addresses near 32k boundaries. So it is worth trying to fix this properly? If it is, here's the first baby step toward that aim. Pegs the negative limit at -32768 instead of -32780, and increases the positive limit a little for powerpc64. This patch is a prerequisite to making rs6000_legitimate_offset_address_p fixes since this one affects insn operand constraints, while other places affect predicates; You can't have insn contraints not covering all operands allowed by the predicate, but the converse is fine. Bootstrapped etc. powerpc64-linux and powerpc-linux. * config/rs6000/rs6000.c (rs6000_mode_dependent_address): Correct offset addressing limits. Index: gcc/config/rs6000/rs6000.c =================================================================== --- gcc/config/rs6000/rs6000.c (revision 189345) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -6409,7 +6409,7 @@ rs6000_mode_dependent_address (const_rtx addr) && GET_CODE (XEXP (addr, 1)) == CONST_INT) { unsigned HOST_WIDE_INT val = INTVAL (XEXP (addr, 1)); - return val + 12 + 0x8000 >= 0x10000; + return val + 0x8000 >= 0x10000 - (TARGET_POWERPC64 ? 8 : 12); } break;