From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60505 invoked by alias); 20 Dec 2019 23:38:41 -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 60469 invoked by uid 89); 20 Dec 2019 23:38:40 -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=HX-Languages-Length:2305, 34-bits, 34bits 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:38:39 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBKNWD9C069196; Fri, 20 Dec 2019 18:38:38 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 2x1129b0mu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2019 18:38:37 -0500 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id xBKNWC70069068; Fri, 20 Dec 2019 18:38:37 -0500 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 2x1129b0mk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2019 18:38:37 -0500 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id xBKNZHlQ032148; Fri, 20 Dec 2019 23:38:36 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma03dal.us.ibm.com with ESMTP id 2wvqc7tajk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2019 23:38:36 +0000 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id xBKNcZ9341156886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Dec 2019 23:38:35 GMT Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 324A46E04E; Fri, 20 Dec 2019 23:38:35 +0000 (GMT) Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B41826E050; Fri, 20 Dec 2019 23:38:34 +0000 (GMT) Received: from ibm-toto.the-meissners.org (unknown [9.32.77.177]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTPS; Fri, 20 Dec 2019 23:38:34 +0000 (GMT) Date: Fri, 20 Dec 2019 23:47:00 -0000 From: Michael Meissner To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn Subject: [PATCH] V11 patch #2 of 15, Use prefixed load for vector extract with large offset Message-ID: <20191220233832.GB28993@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/msg01490.txt.bz2 This patch incorporates large offsets for -mcpu=future when we optimization a vector extract from memory and the memory address previously had been a prefixed address with a large offset. The current code would generate loading up the constant into a temporary and then doing an indexed load. Successive passes would eventually optimize that back into the form we want (having the base register plus a large offset), but it is better to generate the optimial code sooner. I have bootstrapped this change on a little endian power8 system and there were no regressions. Can I check this into the trunk? 2019-12-20 Michael Meissner * config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add support for the offset being 34-bits when -mcpu=future is used. Index: gcc/config/rs6000/rs6000.c =================================================================== --- gcc/config/rs6000/rs6000.c (revision 279553) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -6792,9 +6792,17 @@ rs6000_adjust_vec_address (rtx scalar_re HOST_WIDE_INT offset = INTVAL (op1) + INTVAL (element_offset); rtx offset_rtx = GEN_INT (offset); - if (IN_RANGE (offset, -32768, 32767) + /* 16-bit offset. */ + if (SIGNED_INTEGER_16BIT_P (offset) && (scalar_size < 8 || (offset & 0x3) == 0)) new_addr = gen_rtx_PLUS (Pmode, op0, offset_rtx); + + /* 34-bit offset if we have prefixed addresses. */ + else if (TARGET_PREFIXED_ADDR && SIGNED_INTEGER_34BIT_P (offset)) + new_addr = gen_rtx_PLUS (Pmode, op0, offset_rtx); + + /* Offset overflowed, move offset to the temporary (which will likely + be split), and do X-FORM addressing. */ else { emit_move_insn (base_tmp, offset_rtx); @@ -6825,6 +6833,12 @@ rs6000_adjust_vec_address (rtx scalar_re emit_insn (insn); } + /* Make sure we don't overwrite the temporary if the element being + extracted is variable, and we've put the offset into base_tmp + previously. */ + else if (rtx_equal_p (base_tmp, element_offset)) + emit_insn (gen_add2_insn (base_tmp, op1)); + else { /* Make sure base_tmp is not the same as element_offset. This -- 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