From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 446093888C4C for ; Fri, 1 Apr 2022 20:50:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 446093888C4C Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 231JBsxI007656; Fri, 1 Apr 2022 20:50:28 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3f67b69gfj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Apr 2022 20:50:28 +0000 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 231KoRHF002848; Fri, 1 Apr 2022 20:50:27 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com with ESMTP id 3f67b69gf7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Apr 2022 20:50:27 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 231KXr8J013197; Fri, 1 Apr 2022 20:50:26 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma04dal.us.ibm.com with ESMTP id 3f1tfaumj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Apr 2022 20:50:26 +0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 231KoPWM30212550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Apr 2022 20:50:25 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 34C68C6063; Fri, 1 Apr 2022 20:50:25 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7F949C6055; Fri, 1 Apr 2022 20:50:20 +0000 (GMT) Received: from lexx (unknown [9.160.85.114]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP; Fri, 1 Apr 2022 20:50:20 +0000 (GMT) Message-ID: <1965a581def625fdd99654f70359a558ddd63db9.camel@vnet.ibm.com> Subject: Re: [PATCH] rs6000: Adjust mov optabs for opaque modes [PR103353] From: will schmidt To: "Kewen.Lin" , GCC Patches Cc: Peter Bergner , David Edelsohn , Segher Boessenkool Date: Fri, 01 Apr 2022 15:50:09 -0500 In-Reply-To: <26dce79a-be26-95b0-c14d-51852811969a@linux.ibm.com> References: <26dce79a-be26-95b0-c14d-51852811969a@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: BgAuhwwl4gYOmf6EGzTZotf1ODN7Ux_F X-Proofpoint-GUID: WKmq3M19-2zGpIi36sBXI4X_G7AvDm27 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-04-01_05,2022-03-31_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 priorityscore=1501 adultscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 mlxscore=0 bulkscore=0 malwarescore=0 spamscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204010098 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2022 20:50:35 -0000 On Thu, 2022-03-03 at 16:38 +0800, Kewen.Lin via Gcc-patches wrote: > Hi, > Hi > As PR103353 shows, we may want to continue to expand a MMA built-in > function like a normal function, even if we have already emitted > error messages about some missing required conditions. As shown in > that PR, without one explicit mov optab on OOmode provided, it would > call emit_move_insn recursively. > > So this patch is to allow the mov pattern to be generated when we are > expanding to RTL and have seen errors even without MMA supported, it's > expected that the generated pattern would not cause further ICEs as the > compilation would stop soon after expanding. Is there a testcase, new or existing, that illustrates this error path? > > Bootstrapped and regtested on powerpc64-linux-gnu P8 and > powerpc64le-linux-gnu P9 and P10. > > Is it ok for trunk? > > BR, > Kewen > ------ > > PR target/103353 > > gcc/ChangeLog: > > * config/rs6000/mma.md (define_expand movoo): Move TARGET_MMA condition > check to preparation statements and add handlings for !TARGET_MMA. > (define_expand movxo): Likewise. > > --- > > gcc/config/rs6000/mma.md | 42 ++++++++++++++++++++++++++++++++++------ > > 1 file changed, 36 insertions(+), 6 deletions(-) > > > > diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md > > index 907c9d6d516..f76a87b4a21 100644 > > --- a/gcc/config/rs6000/mma.md > > +++ b/gcc/config/rs6000/mma.md > > @@ -268,10 +268,25 @@ (define_int_attr avvi4i4i4 [(UNSPEC_MMA_PMXVI8GER4PP "pmxvi8ger4pp") > > (define_expand "movoo" > > [(set (match_operand:OO 0 "nonimmediate_operand") > > (match_operand:OO 1 "input_operand"))] > > - "TARGET_MMA" > > + "" > > { > > - rs6000_emit_move (operands[0], operands[1], OOmode); > > - DONE; > > + if (TARGET_MMA) { > > + rs6000_emit_move (operands[0], operands[1], OOmode); > > + DONE; > > + } > > + /* Opaque modes are only expected to be available when MMA is supported, > > + but PR103353 shows we may want to continue to expand a MMA built-in > > + function like a normal function, even if we have already emitted > > + error messages about some missing required conditions. perhaps drop "like a normal function". > > + As shown in that PR, without one explicit mov optab on OOmode provided, > > + it would call emit_move_insn recursively. So we allow this pattern to > > + be generated when we are expanding to RTL and have seen errors, even > > + though there is no MMA support. It would not cause further ICEs as > > + the compilation would stop soon after expanding. */ Testcase would be particularly helpful to illustrate this, i think. TH anks, -Will > > + else if (currently_expanding_to_rtl && seen_error ()) > > + ; > > + else > > + gcc_unreachable (); > > }) > > > > (define_insn_and_split "*movoo" > > @@ -300,10 +315,25 @@ (define_insn_and_split "*movoo" > > (define_expand "movxo" > > [(set (match_operand:XO 0 "nonimmediate_operand") > > (match_operand:XO 1 "input_operand"))] > > - "TARGET_MMA" > > + "" > > { > > - rs6000_emit_move (operands[0], operands[1], XOmode); > > - DONE; > > + if (TARGET_MMA) { > > + rs6000_emit_move (operands[0], operands[1], XOmode); > > + DONE; > > + } > > + /* Opaque modes are only expected to be available when MMA is supported, > > + but PR103353 shows we may want to continue to expand a MMA built-in > > + function like a normal function, even if we have already emitted > > + error messages about some missing required conditions. > > + As shown in that PR, without one explicit mov optab on OOmode provided, > > + it would call emit_move_insn recursively. So we allow this pattern to > > + be generated when we are expanding to RTL and have seen errors, even > > + though there is no MMA support. It would not cause further ICEs as > > + the compilation would stop soon after expanding. */ > > + else if (currently_expanding_to_rtl && seen_error ()) > > + ; > > + else > > + gcc_unreachable (); > > }) > > > > (define_insn_and_split "*movxo" > > -- > > 2.25.1 > >