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 01FFE3857701; Wed, 14 Jun 2023 09:43:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 01FFE3857701 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 0857A1FB; Wed, 14 Jun 2023 02:44:30 -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 7C56D3F663; Wed, 14 Jun 2023 02:43:44 -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 10:43:43 +0100 In-Reply-To: (Richard Biener's message of "Wed, 14 Jun 2023 09:22:09 +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: >> > 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. 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 =E2=80=9Cresult=E2=80=9D. In contrast, a set of memory with an unspec source is in dataflow terms the same as a set of memory with a specified source. (some unspecs actually have well-defined values, it's just that only the target code knows what those well-defined value are.) So a set of memory could only be removed if DSE proves that there are no reads of the set bytes before the next set(s) to the same bytes of memory. And memory is always live. Thanks, Richard