From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40779 invoked by alias); 10 Nov 2015 21:04:14 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 40765 invoked by uid 89); 10 Nov 2015 21:04:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,MAY_BE_FORGED,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: e17.ny.us.ibm.com Received: from e17.ny.us.ibm.com (HELO e17.ny.us.ibm.com) (129.33.205.207) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 10 Nov 2015 21:04:13 +0000 Received: from localhost by e17.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Nov 2015 16:04:10 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e17.ny.us.ibm.com (146.89.104.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 10 Nov 2015 16:04:08 -0500 X-IBM-Helo: d01dlp03.pok.ibm.com X-IBM-MailFrom: wschmidt@linux.vnet.ibm.com X-IBM-RcptTo: gcc-patches@gcc.gnu.org Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 0F64CC90057 for ; Tue, 10 Nov 2015 15:52:18 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tAAL46ll58458210 for ; Tue, 10 Nov 2015 21:04:07 GMT Received: from d01av04.pok.ibm.com (localhost [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tAAL465v009644 for ; Tue, 10 Nov 2015 16:04:06 -0500 Received: from [9.10.86.94] (oc8801110288.ibm.com.rchland.ibm.com [9.10.86.94] (may be forged)) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tAAL45Yu009605 for ; Tue, 10 Nov 2015 16:04:06 -0500 Subject: [PATCH, rs6000] Remove redundant logic from rs6000_secondary_reload_direct_move From: Bill Schmidt To: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Nov 2015 21:04:00 -0000 Message-ID: <1447189445.5668.4.camel@oc8801110288.ibm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15111021-0041-0000-0000-0000024CF364 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01283.txt.bz2 Hi, While investigating another issue, I observed some repeated logic in rs6000_secondary_reload_direct_move (). This patch takes it out. No functional change intended, and quite straightforward, so I'll plan to commit shortly if no concerns are raised. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Thanks, Bill 2015-11-10 Bill Schmidt * config/rs6000/rs6000.c (rs6000_secondary_reload_direct_move): Remove redundant code. Index: gcc/config/rs6000/rs6000.c =================================================================== --- gcc/config/rs6000/rs6000.c (revision 230052) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -17926,29 +17926,8 @@ rs6000_secondary_reload_direct_move (enum rs6000_r } } - if (TARGET_POWERPC64 && size == 16) + else if (size == 8) { - /* Handle moving 128-bit values from GPRs to VSX point registers on - power8 when running in 64-bit mode using XXPERMDI to glue the two - 64-bit values back together. */ - if (to_type == VSX_REG_TYPE && from_type == GPR_REG_TYPE) - { - cost = 3; /* 2 mtvsrd's, 1 xxpermdi. */ - icode = reg_addr[mode].reload_vsx_gpr; - } - - /* Handle moving 128-bit values from VSX point registers to GPRs on - power8 when running in 64-bit mode using XXPERMDI to get access to the - bottom 64-bit value. */ - else if (to_type == GPR_REG_TYPE && from_type == VSX_REG_TYPE) - { - cost = 3; /* 2 mfvsrd's, 1 xxpermdi. */ - icode = reg_addr[mode].reload_gpr_vsx; - } - } - - else if (!TARGET_POWERPC64 && size == 8) - { /* Handle moving 64-bit values from GPRs to floating point registers on power8 when running in 32-bit mode using FMRGOW to glue the two 32-bit values back together. Altivec register classes must be handled