From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 9566D3858D35; Fri, 9 Jun 2023 09:11:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9566D3858D35 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 (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35993YPW012759; Fri, 9 Jun 2023 09:11:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : content-type : mime-version; s=pp1; bh=WmJuXbUL56IK9d/KZzgg9cvrYFnTV1lAylUniVQIm34=; b=Hwvclt0PWglTogXTRc+EJptdA2wiS8jifjp371mZjAuP9So1f3cMdkc61t+D+2dss/Xp 1tJ7jO/dstgCfb4X50II5qGKQqLedt27Fw1JRgS3mgojCsIWVWPbKyxuQCtww7hlJ5RM ow1GWbpJwwHrY+ynpGEXNCSePOQYAXSTDFX51jWVFNmc8Mu3AS8IrwsyJ7Vjxf3vHayT v8QhjmsWqhjyDJm+Sq0vEeaRfbPAA/b6xz8OHoqrUDn3Pt+N1SP+wfxvTRyTzSNGOolI asLxpXkoPUWwrL6B+AjVSR6f9+t6qOu/MlZszST25xP8dOOEAwqIfAxCl8ibNQ8XaVRH WA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r41490fee-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Jun 2023 09:11:03 +0000 Received: from m0353724.ppops.net (m0353724.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 35993gjB013137; Fri, 9 Jun 2023 09:11:03 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r41490fe0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Jun 2023 09:11:03 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3597T2n9024186; Fri, 9 Jun 2023 09:11:02 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([9.208.129.117]) by ppma03dal.us.ibm.com (PPS) with ESMTPS id 3r2a764mdu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Jun 2023 09:11:02 +0000 Received: from smtpav02.wdc07v.mail.ibm.com (smtpav02.wdc07v.mail.ibm.com [10.39.53.229]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3599B1Q865208646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Jun 2023 09:11:01 GMT Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4A0135805D; Fri, 9 Jun 2023 09:11:01 +0000 (GMT) Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D478858059; Fri, 9 Jun 2023 09:11:00 +0000 (GMT) Received: from ltcden2-lp1.aus.stglabs.ibm.com (unknown [9.3.90.43]) by smtpav02.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Fri, 9 Jun 2023 09:11:00 +0000 (GMT) From: Jiufu Guo To: Richard Biener Cc: Richard Sandiford , gcc-patches@gcc.gnu.org, jeffreyalaw@gmail.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 References: <20230609052847.2128612-1-guojiufu@linux.ibm.com> <56dbba43adda001d1668c29e8024c85d@linux.ibm.com> Date: Fri, 09 Jun 2023 17:10:56 +0800 In-Reply-To: (Richard Biener's message of "Fri, 9 Jun 2023 08:51:04 +0000 (UTC)") Message-ID: <7nwn0dgfvj.fsf@ltcden2-lp1.aus.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-GUID: WLIKjmj2ECoIzsN-OsGWuoJjPbM2WbvI X-Proofpoint-ORIG-GUID: gWhOa4wYUi-sBMSY-a-4qAGAyaSgurJT 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_06,2023-06-08_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 adultscore=0 clxscore=1015 malwarescore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306090079 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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, Richard Biener writes: > On Fri, 9 Jun 2023, Richard Sandiford wrote: > >> guojiufu writes: >> > 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])". >> >> I'm not convinced this is correct RTL. (unspec:BLK [(const_int 0)] ...) >> would be though. It's arguably more accurate too, since the effect >> on the stack locations is unspecified rather than predictable. > > powerpc seems to be the only port with a stack_tie that's not > using an UNSPEC RHS. In rs6000.md, it is ; This is to explain that changes to the stack pointer should ; not be moved over loads from or stores to stack memory. (define_insn "stack_tie" [(match_parallel 0 "tie_operand" [(set (mem:BLK (reg 1)) (const_int 0))])] "" "" [(set_attr "length" "0")]) This would be just an placeholder insn, and acts as the comments. UNSPEC_ would works like other targets. While, I'm wondering the concerns on "set (mem:BLK (reg 1)) (const_int 0)". MODEs between SET_DEST and SET_SRC? Thanks for comments! BR, Jeff (Jiufu Guo) > >> Thanks, >> Richard