From patchwork Thu Oct 25 22:57:38 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Segher Boessenkool X-Patchwork-Id: 194322 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 5DEA22C00A3 for ; Fri, 26 Oct 2012 09:59:18 +1100 (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=1351810758; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: From:To:Cc:Subject:Date:Message-Id:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=jILyvsia0QQqLjQj0JYUsTol5mw=; b=RtrMuhbsUCIe4kK bdqxrPorsUlBxVNAJxGW7ECrWosz0/iB2w9EYEDrFDaYGfFuIALNmtfwGp5Ucutb BcEwr0x1pyDTaK2wsC/ymbOLcQwv+GaJ1IvuTSAbTb4ToX7Slbjq20VvGYXF74Xl wHqN43zyWp0h8I8qiSQ7pUBuir70= 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:From:To:Cc:Subject:Date:Message-Id:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=l5UBMjohpo3EEaKhXtycxLZNFLBXpPXvTYZqt2RfpqQ5Ff8peuC67vGrb4HN2k M4U/G6Y77+N/2a+oBLF9TajVyaqzHIhMmn95DHI7B8n4c1/NP08UkBrykVTypvd4 xEA79Y6sC5XnbPabyOmfXdSM42zrfs2Oz3wMdgSlOZxgQ=; Received: (qmail 24870 invoked by alias); 25 Oct 2012 22:59:14 -0000 Received: (qmail 24852 invoked by uid 22791); 25 Oct 2012 22:59:13 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SARE_MSGID_LONG40 X-Spam-Check-By: sourceware.org Received: from gcc1-power7.osuosl.org (HELO gcc1-power7.osuosl.org) (140.211.15.137) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Oct 2012 22:59:07 +0000 Received: from gcc1-power7.osuosl.org (localhost [127.0.0.1]) by gcc1-power7.osuosl.org (8.14.5/8.14.5) with ESMTP id q9PMvgjH011136; Thu, 25 Oct 2012 15:57:42 -0700 Received: (from segher@localhost) by gcc1-power7.osuosl.org (8.14.5/8.14.5/Submit) id q9PMvgwa011015; Thu, 25 Oct 2012 15:57:42 -0700 From: Segher Boessenkool To: gcc-patches@gcc.gnu.org Cc: dje.gcc@gmail.com, Segher Boessenkool Subject: [PATCH] rs6000: Disable generation of lwa in 32-bit mode Date: Thu, 25 Oct 2012 15:57:38 -0700 Message-Id: <06a8399162f2e306f5a48e2a2d35ded562cf2a56.1351204428.git.segher@kernel.crashing.org> 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 Many (most? all?) assemblers (and really the 32-bit ABIs) do not handle lwa and ld properly. Those instructions have a 14-bit offset field, and the low two bits of the instruction are the extended opcode. But the 32-bit toolchains use a 16-bit offset relocation, clobbering the low two bits. See PR27619 and binutils #14758. This works out fine for the most common case (word-aligned ld), but not for most others. This patch disables all lwa insns in 32-bit mode. We can later re-enable it if the assembler used handles it properly, and for lwax and lwaux, and fix the various ld patterns as well, but this is at least a small step in the right direction. gcc: -# of expected passes 108499 -# of unexpected failures 303 +# of expected passes 108508 +# of unexpected failures 295 gfortran: -# of expected passes 40555 -# of unexpected failures 175 +# of expected passes 40582 +# of unexpected failures 148 The lwa pattern must be below the extsw pattern, because the lwa_operand predicate allows registers as well. Changing lwa_operand causes other problems I do not want to deal with right now. Bootstrapped and tested on powerpc64-linux -m64,-m32,-m32/-mpowerpc64. Okay to apply? Segher 2012-10-25 Segher Boessenkool gcc/ * config/rs6000/rs6000.md (sign_extend:SI patterns): Split the memory case off. Merge the two register cases. Change the condition for the memory case to require 64-bit mode. --- gcc/config/rs6000/rs6000.md | 22 ++++++++++++---------- 1 files changed, 12 insertions(+), 10 deletions(-) diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index 2625bd7..5ce7963 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -519,18 +519,9 @@ (define_expand "extendsidi2" "") (define_insn "" - [(set (match_operand:DI 0 "gpc_reg_operand" "=r,r") - (sign_extend:DI (match_operand:SI 1 "lwa_operand" "m,r")))] - "TARGET_POWERPC64 && rs6000_gen_cell_microcode" - "@ - lwa%U1%X1 %0,%1 - extsw %0,%1" - [(set_attr "type" "load_ext,exts")]) - -(define_insn "" [(set (match_operand:DI 0 "gpc_reg_operand" "=r") (sign_extend:DI (match_operand:SI 1 "gpc_reg_operand" "r")))] - "TARGET_POWERPC64 && !rs6000_gen_cell_microcode" + "TARGET_POWERPC64" "extsw %0,%1" [(set_attr "type" "exts")]) @@ -586,6 +577,17 @@ (define_split (const_int 0)))] "") +; The 32-bit ABI has no relocation for DS_LO; the assembler uses a LO instead +; for the @l an lwa instruction uses, overwriting the low two bits in the +; opcode. We could do tricky tricks like adding 2 to the offset, but let's +; not: only allow this instruction in 64-bit mode. +(define_insn "" + [(set (match_operand:DI 0 "gpc_reg_operand" "=r") + (sign_extend:DI (match_operand:SI 1 "lwa_operand" "m")))] + "TARGET_64BIT && rs6000_gen_cell_microcode" + "lwa%U1%X1 %0,%1" + [(set_attr "type" "load_ext")]) + (define_expand "zero_extendqisi2" [(set (match_operand:SI 0 "gpc_reg_operand" "") (zero_extend:SI (match_operand:QI 1 "gpc_reg_operand" "")))]