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 14D0A3858CDA; Wed, 14 Jun 2023 01:55:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 14D0A3858CDA 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 (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35E1opKm016894; Wed, 14 Jun 2023 01:55:36 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=13vYbw3PAGQAF66rlZy99DcfsEhZ9JMKCX5No4O8opg=; b=e2aTCVU8C73pJVFCfuvs9135qtAvJm2ZlmbRcCCbAOCvk2cH+xBY0d8/pD3OXEV9mwgG l+kKKwq0zVIZcW+AUWW0IXIhKdCk1uZHseDh3iGurzAQMTs/gabGWAlMF00Cw0xWef/r bJUDh5QYGzj2etAl36AMbnhMpqpnvLk0nc9nHw+K3HAleDJsdbUP1zkFUOg0NoLct+1L ygNMGItJK6Q8BMwnoVOEQ/ybXY4Rmwbzy5CKTUE+Ks0GGsFosqz3citdVXoQsQpSpQep 1K76txScoCclueOzLP+zBYZoJlDS2vJEEynUblNapPcFQPKrTkudXtf3LvxeRnaU8fC9 PQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r7483r1rg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 01:55:35 +0000 Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 35E1pwl9020651; Wed, 14 Jun 2023 01:55:35 GMT Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r7483r1rb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 01:55:35 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35E1k68e002850; Wed, 14 Jun 2023 01:55:34 GMT Received: from smtprelay06.dal12v.mail.ibm.com ([9.208.130.100]) by ppma03wdc.us.ibm.com (PPS) with ESMTPS id 3r4gt5k8j9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2023 01:55:34 +0000 Received: from smtpav03.wdc07v.mail.ibm.com (smtpav03.wdc07v.mail.ibm.com [10.39.53.230]) by smtprelay06.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35E1tXxf61997490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Jun 2023 01:55:34 GMT Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B47B25805A; Wed, 14 Jun 2023 01:55:33 +0000 (GMT) Received: from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2D63458054; Wed, 14 Jun 2023 01:55:33 +0000 (GMT) Received: from ltcden2-lp1.aus.stglabs.ibm.com (unknown [9.3.90.43]) by smtpav03.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Wed, 14 Jun 2023 01:55:33 +0000 (GMT) From: Jiufu Guo To: Xi Ruoyao Cc: gcc-patches@gcc.gnu.org, segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com, rguenther@suse.de, richard.sandiford@arm.com, jeffreyalaw@gmail.com Subject: Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie References: <20230613122335.2108620-1-guojiufu@linux.ibm.com> Date: Wed, 14 Jun 2023 09:55:30 +0800 In-Reply-To: (Xi Ruoyao's message of "Tue, 13 Jun 2023 20:48:14 +0800") Message-ID: <7nfs6ubyel.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: s3xhzLOVFwthevXI1ZVmiQIxk75rZuOX X-Proofpoint-ORIG-GUID: eI7B-kArL2SSxFQ1oJWwWsK6UKGCHrEh 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-13_24,2023-06-12_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 mlxscore=0 clxscore=1011 impostorscore=0 malwarescore=0 adultscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306140010 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, Xi Ruoyao writes: > On Tue, 2023-06-13 at 20:23 +0800, Jiufu Guo via Gcc-patches wrote: > >> Compare with previous version, this addes ChangeLog and removes >> const_anchor parts. >> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621356.html. > > [Off topic] > > const_anchor is just broken now. See > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104843 and the thread > beginning at > https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591470.html. If > you want to use it for rs6000 I guess you need to fix it first... Thanks so much for pointing out this. It seems about supporting negative value, right? As you say: for 1. "g(0x8123ffff, 0x81240001)", it would be fine. The generated insns are: (insn 5 2 6 2 (set (reg:DI 117) (const_int -2128347135 [0xffffffff81240001])) "negative.c":5:3 681 {*movdi_internal64} (nil)) (insn 6 5 7 2 (set (reg:DI 118) (plus:DI (reg:DI 117) (const_int -2 [0xfffffffffffffffe]))) "negative.c":5:3 66 {*adddi3} (expr_list:REG_EQUAL (const_int -2128347137 [0xffffffff8123ffff]) (nil))) While for 2. "g (0x7fffffff, 0x80000001)", the generated rtl insns: (insn 5 2 6 2 (set (reg:DI 117) (const_int -2147483647 [0xffffffff80000001])) "negative.c":5:3 681 {*movdi_internal64} (nil)) (insn 7 6 8 2 (set (reg:DI 3 3) (const_int 2147483647 [0x7fffffff])) "negative.c":5:3 681 {*movdi_internal64} (nil)) The current const_anchor does not generate sth like: "r3 = r117 - 2" But I would lean to say it is the limitation of current implementation: "0xffffffff80000001" and "0x7fffffff" hit different anchors(even these two values are 'close' on some aspect.) BR, Jeff (Jiufu Guo) > > To me const_anchor needs a complete rework but I don't want to spend my > time on it.