Message ID | YirnIQ1E0C3qlchK@toto.the-meissners.org |
---|---|
State | Committed |
Commit | 3cb27b85a7b977958d53e1a29596ba211d21dde2 |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 394ED3858429 for <patchwork@sourceware.org>; Fri, 11 Mar 2022 06:08:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 394ED3858429 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1646978886; bh=tKUVUUaoF3y7liLiXk+bcZehM8ktMP9Z8ZC04QRcYtw=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=a/X5P5FpKcmh5K/onn+wqqSctAgmsg0WVqrPZ/U/XU73+G+uIya2/l5otCdIUB5ds RDPq8PGRc7pgWupC4j6FrkEQgzLntMwpeTrTa4nwxFxTdjmNoxAkK0WqxccBuPsddq 9TWZW3JMzo0oljravMyJsPnxxUGlNKSA7owpsyjU= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 6CB8E3858D39 for <gcc-patches@gcc.gnu.org>; Fri, 11 Mar 2022 06:07:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6CB8E3858D39 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 22B2p4C4008736; Fri, 11 Mar 2022 06:07:34 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3eqmx5wh1u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Mar 2022 06:07:33 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 22B65emV030514; Fri, 11 Mar 2022 06:07:33 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 3eqmx5wh16-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Mar 2022 06:07:33 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 22B65JTU017124; Fri, 11 Mar 2022 06:07:32 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma02dal.us.ibm.com with ESMTP id 3ekygatus5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Mar 2022 06:07:32 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 22B67V4H5440508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Mar 2022 06:07:31 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8DD65112065; Fri, 11 Mar 2022 06:07:31 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4AA49112064; Fri, 11 Mar 2022 06:07:31 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.77.136.59]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTPS; Fri, 11 Mar 2022 06:07:31 +0000 (GMT) Date: Fri, 11 Mar 2022 01:07:29 -0500 To: gcc-patches@gcc.gnu.org, Michael Meissner <meissner@linux.ibm.com>, Segher Boessenkool <segher@kernel.crashing.org>, David Edelsohn <dje.gcc@gmail.com>, Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com> Subject: [PATCH] Fix DImode to TImode sign extend issue, PR target/104868 Message-ID: <YirnIQ1E0C3qlchK@toto.the-meissners.org> Mail-Followup-To: Michael Meissner <meissner@linux.ibm.com>, gcc-patches@gcc.gnu.org, Segher Boessenkool <segher@kernel.crashing.org>, David Edelsohn <dje.gcc@gmail.com>, Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Sv5joQwKHmk6Mlu_MtoIrtjJ6gSwrxme X-Proofpoint-ORIG-GUID: Ue9iqVHVn2cJX74peatVdJw5-8Vvpo8c X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-10_09,2022-03-11_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 clxscore=1015 mlxlogscore=999 impostorscore=0 malwarescore=0 phishscore=0 spamscore=0 priorityscore=1501 bulkscore=0 lowpriorityscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203110027 X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Michael Meissner via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Michael Meissner <meissner@linux.ibm.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
Fix DImode to TImode sign extend issue, PR target/104868
|
|
Commit Message
Michael Meissner
March 11, 2022, 6:07 a.m. UTC
Fix DImode to TImode sign extend issue, PR target/104898 PR target/104868 had had an issue where my code that updated the DImode to TImode sign extension for power10 failed. In looking at the failure message, the reason is when extendditi2 tries to split the insn, it generates an insn that does not satisfy its constraints: (set (reg:V2DI 65 1) (vec_duplicate:V2DI (reg:DI 0))) The reason is vsx_splat_v2di does not allow GPR register 0 when the will be generating a mtvsrdd instruction. In the definition of the mtvsrdd instruction, if the RA register is 0, it means clear the upper 64 bits of the vector instead of moving register GPR 0 to those bits. When I wrote the extendditi2 pattern, I forgot that mtvsrdd had that behavior so I used a 'r' constraint instead of 'b'. In the rare case where the value is in GPR register 0, this split will fail. This patch uses the right constraint for extendditi2. Note, I was unable to get the example to fail. I built a toolchain, and modified it so libgfortran was built with -flto. But I feel confident that this patch is the right fix for the problem listed in the PR. Can I check this into the master branch? Assuming this patch is accepted, I would incorporate it into the backport for GCC 11. I wasn't planning on backporting it to GCC 10, since the original bug (PR target/104698) does not show up there. 2022-03-10 Michael Meissner <meissner@linux.ibm.com> gcc/ PR target/104868 * config/rs6000/vsx.md (extendditi2): Use a 'b' constraint when moving from a GPR register to an Altivec register. --- gcc/config/rs6000/vsx.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Matheus Castanho reports that the patch I posted fixes the problem in the 1040868 bug report.
On Fri, Mar 11, 2022 at 01:07:29AM -0500, Michael Meissner wrote: > Fix DImode to TImode sign extend issue, PR target/104898 > When I wrote the extendditi2 pattern, I forgot that mtvsrdd had that > behavior so I used a 'r' constraint instead of 'b'. In the rare case > where the value is in GPR register 0, this split will fail. Note that the machine instructions it would generate would work fine: mtvsrdd X,0,Y can be used as a "mtvsrld" always. In fact, generating such code would be better than mtvsrdd always here. Do you want to try that? If not, this is okay for trunk. Thanks! Segher
On Fri, Mar 11, 2022 at 02:41:05PM -0600, Segher Boessenkool wrote: > On Fri, Mar 11, 2022 at 01:07:29AM -0500, Michael Meissner wrote: > > Fix DImode to TImode sign extend issue, PR target/104898 > > > When I wrote the extendditi2 pattern, I forgot that mtvsrdd had that > > behavior so I used a 'r' constraint instead of 'b'. In the rare case > > where the value is in GPR register 0, this split will fail. > > Note that the machine instructions it would generate would work fine: > mtvsrdd X,0,Y can be used as a "mtvsrld" always. In fact, generating > such code would be better than mtvsrdd always here. > > Do you want to try that? If not, this is okay for trunk. Thanks! Right now, it will need support (since we don't have a zero_extendditi2 pattern right now). I am working on optimizations to do this, but right now it is simplest just to use "b".
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md index d0fb92f5985..15bd86dfdfb 100644 --- a/gcc/config/rs6000/vsx.md +++ b/gcc/config/rs6000/vsx.md @@ -5033,7 +5033,7 @@ (define_expand "vsignextend_si_v2di" ;; generate the vextsd2q instruction. (define_insn_and_split "extendditi2" [(set (match_operand:TI 0 "register_operand" "=r,r,v,v,v") - (sign_extend:TI (match_operand:DI 1 "input_operand" "r,m,r,wa,Z"))) + (sign_extend:TI (match_operand:DI 1 "input_operand" "r,m,b,wa,Z"))) (clobber (reg:DI CA_REGNO))] "TARGET_POWERPC64 && TARGET_POWER10" "#"