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 F32E53858D1E; Fri, 9 Jun 2023 08:24:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F32E53858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0353726.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3598IYKa003730; Fri, 9 Jun 2023 08:24:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : in-reply-to : references : message-id : content-type : content-transfer-encoding : mime-version; s=pp1; bh=2PwNP2354nhPKkR1BM/KohlkG+Pq+C231AdoITb6EoM=; b=qQmI3rgOCX1Yj8yVikoQh7lOzuM5ZRDaxsuh41rFxt8gdEuQRHg6XEI6H26kIpD5ao2U 2YOFbQN0UMLBeLfI85A2Ntfsb04cxvvRrKbBMOAmQcCfB/DB34wTchm/dkElfEmQ7oDr WxBGEzUfBuSAUbFtcI7W/NBaP+PbKIm8le78r86Av1/r9EB/5/Hmh0ETh4DR53mAvKXD 4kCOKUguX/SyPMniO1mrxn9SbeRONe3j94Kau5NC+Szf6WAdptyH9HyGPqLLJaC4tKXr ntLvh7ZeuAspLnANO8XQ+8g7BLG7+YTB9xykwL+2jk90p1RDhSNU/qhbXPzcPbkcc5Bo SA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r40f4g4nx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Jun 2023 08:24:47 +0000 Received: from m0353726.ppops.net (m0353726.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3598IiS9003968; Fri, 9 Jun 2023 08:24:46 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r40f4g4ng-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Jun 2023 08:24:46 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3596pjGd001969; Fri, 9 Jun 2023 08:24:45 GMT Received: from smtprelay04.dal12v.mail.ibm.com ([9.208.130.102]) by ppma04dal.us.ibm.com (PPS) with ESMTPS id 3r2a76ksde-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Jun 2023 08:24:45 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay04.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3598Oiug59900318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Jun 2023 08:24:44 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4EF5F5805E; Fri, 9 Jun 2023 08:24:44 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A46EC58045; Fri, 9 Jun 2023 08:24:43 +0000 (GMT) Received: from ltc.linux.ibm.com (unknown [9.5.196.140]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 9 Jun 2023 08:24:43 +0000 (GMT) Date: Fri, 09 Jun 2023 16:24:43 +0800 From: guojiufu To: Richard Biener Cc: gcc-patches@gcc.gnu.org, jeffreyalaw@gmail.com, richard.sandiford@arm.com, segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com Subject: Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors In-Reply-To: References: <20230609052847.2128612-1-guojiufu@linux.ibm.com> Message-ID: <56dbba43adda001d1668c29e8024c85d@linux.ibm.com> X-Sender: guojiufu@linux.ibm.com Content-Type: text/plain; charset=US-ASCII; format=flowed X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: XawxLY5PdV4hah8f9IUMGyIAb_EEazjI X-Proofpoint-GUID: LQKH-_oZL2WmX670CnowFlg7Yd1HGb79 Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.176.26 definitions=2023-06-09_05,2023-06-08_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 malwarescore=0 spamscore=0 impostorscore=0 clxscore=1015 phishscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306090071 X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On 2023-06-09 16:00, Richard Biener wrote: > On Fri, 9 Jun 2023, Jiufu Guo wrote: > >> Hi, >> >> As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P >> (mode))" >> in "try_const_anchors". >> This assert seems correct because the function try_const_anchors cares >> about integer values currently, and modes other than SCALAR_INT_MODE_P >> are not needed to support. >> >> This patch makes sure SCALAR_INT_MODE_P when calling >> try_const_anchors. >> >> This patch is raised when drafting below one. >> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603530.html. >> With that patch, "{[%1:DI]=0;} stack_tie" with BLKmode runs into >> try_const_anchors, and hits the assert/ice. >> >> Boostrap and regtest pass on ppc64{,le} and x86_64. >> Is this ok for trunk? > > Iff the correct fix at all (how can a CONST_INT have BLKmode?) then > I suggest to instead fix try_const_anchors to change > > /* CONST_INT is used for CC modes, but we should leave those alone. > */ > if (GET_MODE_CLASS (mode) == MODE_CC) > return NULL_RTX; > > gcc_assert (SCALAR_INT_MODE_P (mode)); > > to > > /* CONST_INT is used for CC modes, leave any non-scalar-int mode > alone. */ > if (!SCALAR_INT_MODE_P (mode)) > return NULL_RTX; > This is also able to fix this issue. there is a "Punt on CC modes" patch to return NULL_RTX in try_const_anchors. > but as said I wonder how we arrive at a BLKmode CONST_INT and whether > we should have fended this off earlier. Can you share more complete > RTL of that stack_tie? (insn 15 14 16 3 (parallel [ (set (mem/c:BLK (reg/f:DI 1 1) [1 A8]) (const_int 0 [0])) ]) "/home/guojiufu/temp/gdb.c":13:3 922 {stack_tie} (nil)) It is "set (mem/c:BLK (reg/f:DI 1 1) (const_int 0 [0])". This is generated by: rs6000.md (define_expand "restore_stack_block" [(set (match_dup 2) (match_dup 3)) (set (match_dup 4) (match_dup 2)) (match_dup 5) (set (match_operand 0 "register_operand") (match_operand 1 "register_operand"))] "" { rtvec p; operands[1] = force_reg (Pmode, operands[1]); operands[2] = gen_reg_rtx (Pmode); operands[3] = gen_frame_mem (Pmode, operands[0]); operands[4] = gen_frame_mem (Pmode, operands[1]); p = rtvec_alloc (1); RTVEC_ELT (p, 0) = gen_rtx_SET (gen_frame_mem (BLKmode, operands[0]), const0_rtx); operands[5] = gen_rtx_PARALLEL (VOIDmode, p); }) This kind of case (like BLK with const0) is rare, but this would be an intended RTL, and seems not invalid. Thanks so much for your quick and very helpful comments!! BR, Jeff (Jiufu Guo) > >> >> BR, >> Jeff (Jiufu Guo) >> >> gcc/ChangeLog: >> >> * cse.cc (cse_insn): Add SCALAR_INT_MODE_P condition. >> >> --- >> gcc/cse.cc | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/gcc/cse.cc b/gcc/cse.cc >> index 2bb63ac4105..f213fa0faf7 100644 >> *** a/gcc/cse.cc >> --- b/gcc/cse.cc >> *************** >> *** 5003,5009 **** >> if (targetm.const_anchor >> && !src_related >> && src_const >> ! && GET_CODE (src_const) == CONST_INT) >> { >> src_related = try_const_anchors (src_const, mode); >> src_related_is_const_anchor = src_related != NULL_RTX; >> - - >> --- 5003,5010 ---- >> if (targetm.const_anchor >> && !src_related >> && src_const >> ! && GET_CODE (src_const) == CONST_INT >> ! && SCALAR_INT_MODE_P (mode)) >> { >> src_related = try_const_anchors (src_const, mode); >> src_related_is_const_anchor = src_related != NULL_RTX; >> 2.39.3 >> >>