From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 871603858C53; Wed, 14 Jun 2023 16:25:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 871603858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-97454836448so126933166b.2; Wed, 14 Jun 2023 09:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686759922; x=1689351922; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=lnSCBuPCm5fjL9GPNO7kTaSTu3nFWQ898UsY9PpCj18=; b=kkgJ71bkN0izCXUJofuAfiVXkCxfwLDQwYxx58DXYCS2zFwlU/hWargvkwsC748Ylh D+yhJerOG9SlrGOHN5homH4yZsRGvmAOw3fnRi6NTD+xROo7CVpog98WzNdwNnfI5XqO l42OnNfbUCqe3YRCjfXrpQ0LZtvnY17jYf692O0dVcU3Xse7pySj7FaIVJ8vAN97WDgx IkGUhAXRQLNskTLhCHuUum3x9qc7ctCt+Lp2o12BDMp2v2hMn9D+RnYqhGPoYvGCr/qa M3HHCkrqyhh8l65mkbVccM01+7CkySDWBozPb6DxyGtPi0OfZl5C43V97cRKqb1L9kWy aT7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686759922; x=1689351922; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lnSCBuPCm5fjL9GPNO7kTaSTu3nFWQ898UsY9PpCj18=; b=PoODtpSI9OT70uNCq74lIeAXAL8dazMKTHRwhPQn2v+atEp8YjR4hURkpcu2wXKgmM t//gThuw1Kap3ByTBrO6R0YcTgyl87iA2iUwLP268I4g/c6j7GChs/yNljS9+viCdVoT FnFNwyyacG3V2pgpl89FGUrmz++gW7nIMZSId59EgTPTW2qrcekt23bkXd0tWOAZ5gdJ /iFJJoDzpXiG2H538cqaz9bFiith3bTJl+jnyQoBXj9IaMxCUfzXZ/J0FV+kBWgR6+w1 +YjI/M2GRdIBgW17OJISt5VzbQd/vUNnAXHfsTQpQyTcEBvFgXjnrTmfKXLdtCqmae0o w3OA== X-Gm-Message-State: AC+VfDwn6ZWhEGd9h/O2STZ48qLDLy6RDyLF2EofNPDlGiIc+6Pex+Eo 1jg0Gjo+2UQ1gyjTfsv8bWU= X-Google-Smtp-Source: ACHHUZ7HrBMksFBBj9SFSf5eycONVw1vTsiIt6Btx8tukduRML9+KkDN5ZZyw5VHf5r22YAN6DQKBg== X-Received: by 2002:a17:907:2d91:b0:97d:cc56:d9bc with SMTP id gt17-20020a1709072d9100b0097dcc56d9bcmr14252284ejc.51.1686759921795; Wed, 14 Jun 2023 09:25:21 -0700 (PDT) Received: from smtpclient.apple (dynamic-077-002-002-111.77.2.pool.telefonica.de. [77.2.2.111]) by smtp.gmail.com with ESMTPSA id op7-20020a170906bce700b00977d0f1c5bcsm8188566ejb.69.2023.06.14.09.25.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jun 2023 09:25:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie Date: Wed, 14 Jun 2023 18:25:10 +0200 Message-Id: References: <20230614153816.GX19790@gate.crashing.org> Cc: Richard Biener , Jiufu Guo , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com, richard.sandiford@arm.com, jeffreyalaw@gmail.com In-Reply-To: <20230614153816.GX19790@gate.crashing.org> To: Segher Boessenkool X-Mailer: iPhone Mail (20F66) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,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: > Am 14.06.2023 um 17:41 schrieb Segher Boessenkool : >=20 > =EF=BB=BFHi! >=20 >> On Wed, Jun 14, 2023 at 07:59:04AM +0000, Richard Biener wrote: >>> On Wed, 14 Jun 2023, Jiufu Guo wrote: >>> 3. "set (mem/c:DI (reg/f:DI 1 1) unspec:DI (const_int 0 [0]) >>> UNSPEC_TIE". >>> This avoids using BLK on unspec, but using DI. >>=20 >> That gives the MEM a size which means we can interpret the (set ..) >> as killing a specific area of memory, enabling DSE of earlier >> stores. >=20 > Or DSE can delete this tie even, if it can see some later store to the > same location without anything in between that can read what the tie > stores. >=20 > BLKmode avoids all of this. You can call that elegant, you can call it > cheating, you can call it many things -- but it *works*. >=20 >> AFAIU this special instruction is only supposed to prevent >> code motion (of stack memory accesses?) across this instruction? >=20 > Form rs6000.md: > ; This is to explain that changes to the stack pointer should > ; not be moved over loads from or stores to stack memory. > (define_insn "stack_tie" That suggests it=E2=80=99s the hard register value that=E2=80=98s protected,= not the memory pointed to. I suppose that means an unspec volatile with th= e reg as input would serve the same? Or maybe that=E2=80=99s not the whole story. > and from rs6000-logue.cc: > /* This ties together stack memory (MEM with an alias set of frame_alias_s= et) > and the change to the stack pointer. */ > static void > rs6000_emit_stack_tie (rtx fp, bool hard_frame_needed) I cannot make sense of that comment, but not sure if I really want to know =E2= =80=A6 > A big reason this is needed is because of all the hard frame pointer > stuff, which the generic parts of GCC require, but there is no register > for that in the Power architecture. Nothing is an issue here in most > cases, but sometimes we need to do unusual things to the stack, say for > alloca. >=20 >> I'd say a >>=20 >> (may_clobber (mem:BLK (reg:DI 1 1))) >=20 > "clobber" always means "may clobber". (clobber X) means X is written > with some unspecified value, which may well be whatever value it > currently holds. Via some magical means or whatever, there is no > mechanism specified, just the effects :-) >=20 >> 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 > It is the same thing. "clobber" means the same thing as "set", except > the value that is written is not specified. >=20 >> I suppose stack_tie should be less strict than the documented >> (clobber (mem:BLK (const_int 0))) (clobber all memory). >=20 > "clobber" is nicer than the set to (const_int 0). Does it work though? > All this code is always fragile :-/ I'm all for this change, don't get > me wrong, but preferably things stay in working order. >=20 > We use "stack_tie" as a last resort heavy hammer anyway, in all normal > cases we explain the actual data flow explicitly and correctly, also > between the various registers used in the *logues. >=20 >=20 > Segher