From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 372CB3858CDA; Wed, 14 Jun 2023 10:02:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 372CB3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2607D1FB; Wed, 14 Jun 2023 03:03:08 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 98B463F71E; Wed, 14 Jun 2023 03:02:22 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Jiufu Guo , Segher Boessenkool , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com, jeffreyalaw@gmail.com, richard.sandiford@arm.com Cc: Jiufu Guo , Segher Boessenkool , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.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> <20230613183320.GU19790@gate.crashing.org> <7no7liadru.fsf@ltcden2-lp1.aus.stglabs.ibm.com> Date: Wed, 14 Jun 2023 11:02:21 +0100 In-Reply-To: (Richard Biener's message of "Wed, 14 Jun 2023 09:52:37 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-21.8 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Richard Biener writes: > On Wed, 14 Jun 2023, Richard Sandiford wrote: > >> Richard Biener writes: >> > On Wed, 14 Jun 2023, Richard Sandiford wrote: >> > >> >> Richard Biener writes: >> >> > AFAIU this special instruction is only supposed to prevent >> >> > code motion (of stack memory accesses?) across this instruction? >> >> > I'd say a >> >> > >> >> > (may_clobber (mem:BLK (reg:DI 1 1))) >> >> > >> >> > might be more to the point? I've used "may_clobber" which doesn't >> >> > exist since I'm not sure whether a clobber is considered a kill. >> >> > The docs say "Represents the storing or possible storing of an=20 >> >> > unpredictable..." - what is it? Storing or possible storing? >> >>=20 >> >> I'd also understood it to be either. As in, it is a may-clobber >> >> that can be used for must-clobber. Alternatively: the value stored >> >> is unpredictable, and can therefore be the same as the current value. >> >>=20 >> >> I think the main difference between: >> >>=20 >> >> (clobber (mem:BLK ?)) >> >>=20 >> >> and >> >>=20 >> >> (set (mem:BLK ?) (unspec:BLK ?)) >> >>=20 >> >> is that the latter must happen for correctness (unless something >> >> that understands the unspec proves otherwise) whereas a clobber >> >> can validly be dropped. So for something like stack_tie, a set >> >> seems more correct than a clobber. >> > >> > How can a clobber be validly dropped? For the case of stack >> > memory if there's no stack use after it it could be elided >> > and I suppose the clobber itself can be moved. But then >> > the function return is a stack use as well. >> > >> > Btw, with the same reason the (set (mem:...)) could be removed, no? >> > Or is the (unspec:) SET_SRC having implicit side-effects that >> > prevents the removal (so rs6000 could have its stack_tie removed)? >> > >> > That said, I fail to see how a clobber is special here. >>=20 >> Clobbers are for side-effects. They don't start a def-use chain. >> E.g. any use after a full clobber is an uninitialised read rather >> than a read of the clobber ?result?. > > I see. So > > (parallel > (unspec stack_tie) > (clobber (mem:BLK ...))) > > then? I suppose it needs to be an unspec_volatile? Yeah, it would need to be unspec_volatile, at which point it becomes quite a big hammer. > It feels like the stack_ties are a delicate hack preventing enough but > not too much optimization ... Yup. I think the only non-hacky way would be to have dedicated RTL for memory becoming valid and becoming invalid. Anything else is a compromise. But TBH, I still think the (set (mem:BLK =E2=80=A6) (unspec:BLK =E2=80=A6))= strikes the right balance, unless there's a specific argument otherwise. The effect on memory isn't a side effect (contrary to what clobber implies) but instead is the main purpose of allocating and deallocating stack memory. Thanks, Richard