From patchwork Wed May 18 14:07:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kewen.Lin" X-Patchwork-Id: 1632834 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=gT8H2E4Y; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4L3FGV6NZdz9sGY for ; Thu, 19 May 2022 00:09:06 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 19E83384F02E for ; Wed, 18 May 2022 14:09:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 19E83384F02E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1652882942; bh=MezNBufBO6l9en0bDHNycOyQJE2BrhqP3SwHRFXDs4E=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=gT8H2E4Y2w0/hZkC6x6VtZzfiQ+UDMhWRG+wDv/XHuKO54IkY7WAje+IVD3udkl9K wzy+makF8CsYa0gwcoLnZInNarHQF0fvR64DeiVkVkYWHrUqpg+RNijyYBcBhShzPB oJ3saLLmBP9X1gZfyFSmjfZKz0egVreprGwNGl2k= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id ACC503846030 for ; Wed, 18 May 2022 14:07:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ACC503846030 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24IDplSe011238; Wed, 18 May 2022 14:07:57 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g5228ggnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 May 2022 14:07:57 +0000 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 24IE0D6d024359; Wed, 18 May 2022 14:07:56 GMT Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3g5228ggmc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 May 2022 14:07:56 +0000 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 24IE2UOq013106; Wed, 18 May 2022 14:07:55 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma03fra.de.ibm.com with ESMTP id 3g2428vq7j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 May 2022 14:07:54 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 24IDs0gg55247260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 May 2022 13:54:00 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6175CA404D; Wed, 18 May 2022 14:07:52 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 40372A4040; Wed, 18 May 2022 14:07:50 +0000 (GMT) Received: from [9.197.252.204] (unknown [9.197.252.204]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 18 May 2022 14:07:49 +0000 (GMT) Message-ID: <09c34b29-feea-d26e-2c4f-5e096ab286bc@linux.ibm.com> Date: Wed, 18 May 2022 22:07:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: GCC Patches Subject: [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353] X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 7ztI-Tim5-wgyC048iVFtvMb_4kGTbXU X-Proofpoint-GUID: q13FHha0ggYdzcQwLn42_mPZmMWXb54t X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-18_05,2022-05-17_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 mlxscore=0 spamscore=0 adultscore=0 phishscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205180083 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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-Patchwork-Original-From: "Kewen.Lin via Gcc-patches" From: "Kewen.Lin" Reply-To: "Kewen.Lin" Cc: Peter Bergner , David Edelsohn , Segher Boessenkool Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" 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. Bootstrapped and regtested on powerpc64-linux-gnu P8 and powerpc64le-linux-gnu P9 and P10. v3: Update test case with dg-excess-errors. v2: Polish some comments and add one test case as Will and Peter suggested. https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592916.html v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591150.html 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/testsuite/ChangeLog: * gcc.target/powerpc/pr103353.c: New test. --- gcc/config/rs6000/mma.md | 42 ++++++++++++++++++--- gcc/testsuite/gcc.target/powerpc/pr103353.c | 22 +++++++++++ 2 files changed, 58 insertions(+), 6 deletions(-) create mode 100644 gcc/testsuite/gcc.target/powerpc/pr103353.c diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md index 907c9d6d516..746a77a0957 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, 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 "*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, even if we have already emitted error messages about some + missing required conditions. As shown in that PR, without one + explicit mov optab on XOmode 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" diff --git a/gcc/testsuite/gcc.target/powerpc/pr103353.c b/gcc/testsuite/gcc.target/powerpc/pr103353.c new file mode 100644 index 00000000000..5d519fb1b7b --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/pr103353.c @@ -0,0 +1,22 @@ +/* { dg-require-effective-target powerpc_altivec_ok } */ +/* If the default cpu type is power10 or later, MMA is enabled by default. + To keep the test point available all the time, this case specifies + -mdejagnu-cpu=power6 to make it be tested without MMA. */ +/* { dg-options "-maltivec -mdejagnu-cpu=power6" } */ + +/* Verify there is no ICE and don't check the error messages on MMA + requirement since they could be fragile and are not test points + of this case. */ +/* { dg-excess-errors "pr103353" } */ + +void +foo (__vector_pair *dst, double *x) +{ + dst[0] = __builtin_vsx_lxvp (0, (__vector_pair *)(void *)x); +} + +void +bar (__vector_pair *src, double *x) +{ + __builtin_vsx_stxvp (src[0], 0, (__vector_pair *)(void *)x); +}