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 5C53C3858D38; Wed, 14 Jun 2023 03:00:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5C53C3858D38 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 (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35E2mvXP005090; Wed, 14 Jun 2023 03:00:22 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 : mime-version : content-type : content-transfer-encoding; s=pp1; bh=MoUj9t7j8LbknxA0NFXRgxgIMdQo06dPUjFReKEc0Pc=; b=lwM/EniHP86qLckjeIqhrkF+7j1IBD8JGRJhs8fnYCgMJPMjM/fqW1t55oIG1WvTYfjS 9+jIWuBKfN3irdR/n/NBXXyT5a2NhSpLERqUKuDdUQE/mDo4zuVmbU6Ucwa3Uif1xqUh /HvDLRui2/g3t/gBHNw0YUjJtQ6U9mfvMjsAQxUroeiQfM82TsqF6z2lNbdiJ1uyIJ+2 4hlQRvBcegnRGY+DvTX3kWO5JipWkg7vHIk8uDGb7xfwZDi2rhrArKkXvDFZt4BEvQoE FruMFC6HqcwyUFAuB/EivvVpkFH54HJARlkRfKbiLhs62TEC/ySo9NZIy9YKGrGxMpjr cg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r753nr55a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 03:00:21 +0000 Received: from m0360072.ppops.net (m0360072.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 35E2qGf7014349; Wed, 14 Jun 2023 03:00:21 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r753nr54t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 03:00:21 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35E0bI7S011245; Wed, 14 Jun 2023 03:00:20 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([9.208.129.114]) by ppma04wdc.us.ibm.com (PPS) with ESMTPS id 3r4gt5khfv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 03:00:20 +0000 Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35E30Jk425362688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Jun 2023 03:00:19 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1F02B58043; Wed, 14 Jun 2023 03:00:19 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3D0258055; Wed, 14 Jun 2023 03:00:18 +0000 (GMT) Received: from ltcden2-lp1.aus.stglabs.ibm.com (unknown [9.3.90.43]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTPS; Wed, 14 Jun 2023 03:00:18 +0000 (GMT) From: Jiufu Guo To: David Edelsohn Cc: Segher Boessenkool , gcc-patches@gcc.gnu.org, linkw@gcc.gnu.org, bergner@linux.ibm.com, rguenther@suse.de, richard.sandiford@arm.com Subject: Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie References: <20230612131919.269681-1-guojiufu@linux.ibm.com> <7nv8fscdka.fsf@ltcden2-lp1.aus.stglabs.ibm.com> <20230613181446.GT19790@gate.crashing.org> Date: Wed, 14 Jun 2023 11:00:16 +0800 In-Reply-To: (David Edelsohn's message of "Tue, 13 Jun 2023 14:59:35 -0400") Message-ID: <7n4jnabven.fsf@ltcden2-lp1.aus.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-GUID: DU2NlTBVSj6PWFvAKEtAKXjybvMrtcAr X-Proofpoint-ORIG-GUID: QUHb6YEPo-3aCc0b_TPzx863-4skkbPK 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-13_24,2023-06-12_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 mlxscore=0 bulkscore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306140018 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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 Segher, David, David Edelsohn writes: > On Tue, Jun 13, 2023 at 2:16=E2=80=AFPM Segher Boessenkool > wrote: >> >> Hi! >> >> On Tue, Jun 13, 2023 at 10:15:49AM +0800, Jiufu Guo wrote: >> > David Edelsohn writes: >> > > >> > > This definitely seems to be a better solution. >> > > >> > > The TARGET_CONST_ANCHOR change should not be part of this patch. Al= so >> > > there is no ChangeLog for the patch. >> > >> > Thanks a lot for your quick review!! And sorry for the sending this pa= tch >> > in a hurry. I would update the patch accordingly. >> >> > > This generally looks correct and consistent with other ports. I want >> > > to give Segher a chance to double check it, if he wishes. >> >> The documentation is very clear that the only thing for which you can >> have BLKmode is "mem". Not unspec, only "mem". >> >> Let's not do this. The existing code has clear and obvious semantics, >> which is documented as well -- there is no reason to make it worse in >> every respect. Thanks for all your insight comments! Yeap, while "unspec:BLK" is very widely used already on various ports. And it seems a few place is using BLKmode without strictly align with the document :( It would not be very good thing, but maybe no better solutions. For existing code "set (mem/c:BLK (reg/f:DI 1 1) (const_int 0 [0])" Since it is a set, the operand set_src should be valid for the mode of the set_dest. While set_src is 'const_int 0'. And this 'set' may be mis-readed as 'a memory is zeroed' or 'no-op to a mem'. Using unspec here would just say this is an special operation instead a normal 'const_int 0'. BR, Jeff (Jiufu Guo) > > Segher, > > Unfortunately, GCC now is inconsistent and this response is incorrect. > The documentation is out of date or was ignored and the "facts on the > ground" contradict your review. > > Yes, (const_int 0) is supposed to be a general no-op and BLKmode only > is supposed to be used for MEM, but other major targets (arm, aarch64, > riscv, s390) all use unspec:BLK and specifically UNSPEC_TIE. rs6000 > is the only port that does not follow this convention. The middle-end > has adapted to the behavior of all of the other targets, whether that > conformed to the documentation or not. The rs6000 port needs to be > fixed and Jiufu's approach is the correct one, consistent with all > other targets for stack tie. If the documentation differs, the > documentation needs to be updated, not a different approach for the > rs6000 port. Jiufu's patch is correct. > > Thanks, David