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 E5FBD3858002; Wed, 14 Jun 2023 09:04:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E5FBD3858002 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 D52FF1FB; Wed, 14 Jun 2023 02:05:06 -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 545903F663; Wed, 14 Jun 2023 02:04:21 -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:04:20 +0100 In-Reply-To: (Richard Biener's message of "Wed, 14 Jun 2023 07:59:04 +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: > 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? 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. I think the main difference between: (clobber (mem:BLK =E2=80=A6)) and (set (mem:BLK =E2=80=A6) (unspec:BLK =E2=80=A6)) 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. Thanks, Richard