From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 6F4F93858D38; Wed, 14 Jun 2023 09:18:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6F4F93858D38 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1686734298; bh=X0p73AxoYyZ7KC6p+a/wDdFzQJO9467CBymUhLmeqfU=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=D1fKPyPRLIQrVCnlpXX8PCTjh2qsKOPXg43VC188GLx3kukxwIm1nNOWyv7Bh0Twk kZDIUc13xFljUjkTbSd50cDjQmTMaFzZbSKHKoaAlJ76IlHaxvj23XM+9GYronwzNZ lPNezHxQwMyQFMLmpNR4BGkkEsNLUl20FlxNKSqo= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 192B6662A7; Wed, 14 Jun 2023 05:18:16 -0400 (EDT) Message-ID: <6bd54083cadc5d5720afb01f9ab202a2ac748863.camel@xry111.site> Subject: Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie From: Xi Ruoyao To: Jiufu Guo 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 Date: Wed, 14 Jun 2023 17:18:15 +0800 In-Reply-To: <7nfs6ubyel.fsf@ltcden2-lp1.aus.stglabs.ibm.com> References: <20230613122335.2108620-1-guojiufu@linux.ibm.com> <7nfs6ubyel.fsf@ltcden2-lp1.aus.stglabs.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.3 MIME-Version: 1.0 X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2023-06-14 at 09:55 +0800, Jiufu Guo wrote: > Hi, >=20 > Xi Ruoyao writes: >=20 > > On Tue, 2023-06-13 at 20:23 +0800, Jiufu Guo via Gcc-patches wrote: > >=20 > > > Compare with previous version, this addes ChangeLog and removes > > > const_anchor parts. > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621356.html. > >=20 > > [Off topic] > >=20 > > const_anchor is just broken now.=C2=A0 See > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104843=C2=A0and the thre= ad > > beginning at > > https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591470.html.=C2=A0= If > > you want to use it for rs6000 I guess you need to fix it first... >=20 > Thanks so much for pointing out this.=C2=A0 It seems about supporting > negative value, right? >=20 > As you say: for 1. "g(0x8123ffff, 0x81240001)", it would be fine. >=20 > The generated insns are: > (insn 5 2 6 2 (set (reg:DI 117) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (const_int -2128347135 [0xffff= ffff81240001])) "negative.c":5:3 681 {*movdi_internal64} > =C2=A0=C2=A0=C2=A0=C2=A0 (nil)) > (insn 6 5 7 2 (set (reg:DI 118) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (plus:DI (reg:DI 117) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (const= _int -2 [0xfffffffffffffffe]))) "negative.c":5:3 66 {*adddi3} > =C2=A0=C2=A0=C2=A0=C2=A0 (expr_list:REG_EQUAL (const_int -2128347137 [0xf= fffffff8123ffff]) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (nil))) >=20 > While for 2. "g (0x7fffffff, 0x80000001)", the generated rtl insns: > (insn 5 2 6 2 (set (reg:DI 117) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (const_int -2147483647 [0xffff= ffff80000001])) "negative.c":5:3 681 {*movdi_internal64} > =C2=A0=C2=A0=C2=A0=C2=A0 (nil)) > (insn 7 6 8 2 (set (reg:DI 3 3) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (const_int 2147483647 [0x7ffff= fff])) "negative.c":5:3 681 {*movdi_internal64} > =C2=A0=C2=A0=C2=A0=C2=A0 (nil)) >=20 > The current const_anchor does not generate sth like: "r3 =3D 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.) The generic issue here is to fix (not "papering over") the signed overflow, we need to perform the addition in a target machine mode. We may always use Pmode (IIRC const_anchor was introduced for optimizing some constant addresses), but can we do better? Should we try addition in both DImode and SImode for a 64-bit capable machine? Or should we even try more operations than addition (for eg bit operations like xor or shift)? Doing so will need to create a new target hook for const anchoring, this is the "complete rework" I meant. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University