From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82706 invoked by alias); 20 Dec 2019 23:47:37 -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 82697 invoked by uid 89); 20 Dec 2019 23:47:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=vsxmd, UD:vsx.md, vsx.md, sk:vsx_ext X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Dec 2019 23:47:35 +0000 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBKNjEgd046703; Fri, 20 Dec 2019 18:47:33 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 2x0xcd9jmx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2019 18:47:33 -0500 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id xBKNjknq047740; Fri, 20 Dec 2019 18:47:33 -0500 Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com with ESMTP id 2x0xcd9jmr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2019 18:47:33 -0500 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id xBKNjmFm012627; Fri, 20 Dec 2019 23:47:32 GMT Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by ppma03wdc.us.ibm.com with ESMTP id 2wvqc7bhcy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2019 23:47:32 +0000 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id xBKNlVah55837086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Dec 2019 23:47:31 GMT Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 33B52BE053; Fri, 20 Dec 2019 23:47:31 +0000 (GMT) Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8CB6BE04F; Fri, 20 Dec 2019 23:47:30 +0000 (GMT) Received: from ibm-toto.the-meissners.org (unknown [9.32.77.177]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTPS; Fri, 20 Dec 2019 23:47:30 +0000 (GMT) Date: Fri, 20 Dec 2019 23:49:00 -0000 From: Michael Meissner To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn Subject: [PATCH] V11 patch #3 of 15, Use 'Q' constraint for variable vector extract from memory Message-ID: <20191220234728.GC28993@ibm-toto.the-meissners.org> Mail-Followup-To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn References: <20191220231507.GA18386@ibm-toto.the-meissners.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191220231507.GA18386@ibm-toto.the-meissners.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2019-12/txt/msg01491.txt.bz2 As I mentioned in the intro, for the case where we are optimizing the extract of a variable element from a vector in memory, the current code takes a regular address, and the temporary that holds the byte offset, and tries to generate a new address. In particular, it failed when the vector was a PC-relative address, because it didn't have enough temporary registers, and it used the temporary to hold the byte offset to hold the address. Initially in doing these patches, I reworked the constraints for prefixed and non-prefixed memory so we could identify when we needed a second temporary. Then I realized that eventaully we will want to generate an X-FORM (register + register) address, and it was just simpler to use the 'Q' constraint, and have the register allocator put the address into a register. I have verified that the bug is indeed fixed (patch #15 will include the new tests for this). I have also bootstrapped the compiler on a little endian power8 machine and there were no regressions in the test suite. Can I check this patch into the trunk? 2019-12-20 Michael Meissner * config/rs6000/vsx.md (vsx_extract__var, VSX_D iterator): Use 'Q' for memory constraints because we need to do an X-FORM load with the variable index. (vsx_extract_v4sf_var): Use 'Q' for memory constraints because we need to do an X-FORM load with the variable index. (vsx_extract__var, VSX_EXTRACT_I iterator):Use 'Q' for memory constraints because we need to do an X-FORM load with the variable index. (vsx_extract__mode_var): Use 'Q' for memory constraints because we need to do an X-FORM load with the variable index. Index: gcc/config/rs6000/vsx.md =================================================================== --- gcc/config/rs6000/vsx.md (revision 279597) +++ gcc/config/rs6000/vsx.md (working copy) @@ -3245,10 +3245,11 @@ (define_insn "vsx_vslo_" "vslo %0,%1,%2" [(set_attr "type" "vecperm")]) -;; Variable V2DI/V2DF extract +;; Variable V2DI/V2DF extract. Use 'Q' for the memory because we will +;; ultimately have to convert the address into base + index. (define_insn_and_split "vsx_extract__var" [(set (match_operand: 0 "gpc_reg_operand" "=v,wa,r") - (unspec: [(match_operand:VSX_D 1 "input_operand" "v,m,m") + (unspec: [(match_operand:VSX_D 1 "input_operand" "v,Q,Q") (match_operand:DI 2 "gpc_reg_operand" "r,r,r")] UNSPEC_VSX_EXTRACT)) (clobber (match_scratch:DI 3 "=r,&b,&b")) @@ -3318,7 +3319,7 @@ (define_insn_and_split "*vsx_extract_v4s ;; Variable V4SF extract (define_insn_and_split "vsx_extract_v4sf_var" [(set (match_operand:SF 0 "gpc_reg_operand" "=wa,wa,?r") - (unspec:SF [(match_operand:V4SF 1 "input_operand" "v,m,m") + (unspec:SF [(match_operand:V4SF 1 "input_operand" "v,Q,Q") (match_operand:DI 2 "gpc_reg_operand" "r,r,r")] UNSPEC_VSX_EXTRACT)) (clobber (match_scratch:DI 3 "=r,&b,&b")) @@ -3681,7 +3682,7 @@ (define_insn_and_split "*vsx_extract__var" [(set (match_operand: 0 "gpc_reg_operand" "=r,r,r") (unspec: - [(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,m") + [(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,Q") (match_operand:DI 2 "gpc_reg_operand" "r,r,r")] UNSPEC_VSX_EXTRACT)) (clobber (match_scratch:DI 3 "=r,r,&b")) @@ -3701,7 +3702,7 @@ (define_insn_and_split "*vsx_extract_ 0 "gpc_reg_operand" "=r,r,r") (zero_extend: (unspec: - [(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,m") + [(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,Q") (match_operand:DI 2 "gpc_reg_operand" "r,r,r")] UNSPEC_VSX_EXTRACT))) (clobber (match_scratch:DI 3 "=r,r,&b")) -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.ibm.com, phone: +1 (978) 899-4797