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 B7A913858026 for ; Fri, 27 Nov 2020 16:31:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B7A913858026 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 62A8B1516; Fri, 27 Nov 2020 08:31:42 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E2B4B3F71F; Fri, 27 Nov 2020 08:31:41 -0800 (PST) From: Richard Sandiford To: Michael Matz Mail-Followup-To: Michael Matz , Jeff Law via Gcc-patches , richard.sandiford@arm.com Cc: Jeff Law via Gcc-patches Subject: Re: [00/23] Make fwprop use an on-the-side RTL SSA representation References: Date: Fri, 27 Nov 2020 16:31:40 +0000 In-Reply-To: (Michael Matz's message of "Fri, 27 Nov 2020 15:56:38 +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=-6.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 16:31:44 -0000 Michael Matz writes: > Hello, > > On Thu, 26 Nov 2020, Richard Sandiford via Gcc-patches wrote: > >> >> The aim is only to provide a different view of existing RTL instructi= ons. >> >> Unlike gimple, and unlike (IIRC) the old RTL SSA project from way bac= k, >> >> the new framework isn't a =E2=80=9Cnative=E2=80=9D SSA representation= . This means that >> >> all inputs to a phi node for a register R are also definitions of >> >> register R; no move operation is =E2=80=9Chidden=E2=80=9D in the phi = node. >> > Hmm, I'm trying to parse what the last phrase means.=C2=A0 Does it mea= n that >> > the "hidden copy" problem for out-of-ssa is avoided?=C2=A0 And if so, = how is >> > that maintained over time.=C2=A0 Things like copy-prop will tend to in= troduce >> > those issues even if they didn't originally exist. >>=20 >> Yeah, the phi nodes simply say which definition of register R provides >> the value of R on a particular incoming edge. That definition will >> itself be a phi node for R, an artificial definition of R created by DF >> (e.g. for incoming function arguments or for EH data registers), or an >> actual instruction that sets R. >>=20 >> In other words, the SSA form is a purely on-the-side thing and the >> underlying RTL instructions are maintained in the same way as normal. >> The SSA form can be deleted at any time without performing a separate >> out-of-ssa step. In that respect it's different from cfglayout, >> for example. > > Hmm, I don't see how that answers Jeffs question, if I got it correctly.= =20=20 > If I didn't get it correctly let me ask my own version of the question :) > > (I haven't studied your implementation in detail, if I had maybe answers= =20 > to the below would become obvious, sorry if so :) ) >=20=20 > So, you're saying that in your implementation the operands of PHIs can be= =20 > PHIs and real defs. Specifically real defs of the same register (or memory, for memory phis). > Further you say nothing about any restriction in RTL=20 > instruction moving and/or propagation. The RTL SSA form doesn't add any extra restrictions beyond those that apply to non-SSA RTL passes. But it also doesn't take any restrictions away. In other words, the changes that RTL SSA passes make to RTL instructions are the same as those that non-SSA RTL passes would make. The SSA form is just there to make it easier to process use-def chains (and also to process live ranges, to a limited extent). > So, then let's start with one of=20 > the prime examples of SSA deconstruction problems, the lost swap, and how= =20 > it comes to be: we start with a swap: > > x =3D ..., y =3D ... > if (cond) > tmp=3Dx, x=3Dy, y=3Dtmp > > (1) into SSA: > > x0 =3D ..., y0 =3D ... > if (cond) > tmp =3D x0, x1=3Dy0, y1=3Dtmp; > x2 =3D PHI(x0,x1), y2 =3D PHI(y0,y1) > > (2) copy-prop: > > x0 =3D ..., y0 =3D ... > if (cond) > ; > x2 =3D PHI(x0,y0), y2 =3D PHI(y0,x0) So the point is that this isn't what the RTL would look like even when using RTL SSA. Putting y0 in x2 PHI and x0 in the y2 PHI is representationally invalid. Like I say, this isn't a =E2=80=9Cnative=E2=80=9D SSA form: it's just using= SSA constructs to represent dataflow in normal RTL. > Now you're also saying that the SSA form can simply be deleted without an= y=20 > consideration of the parallel copy nature, i.e. no real out-of-ssa phase.= =20=20 > In the above example that would lead to wrong code, so that can't be it.= =20=20 > So what in your representation avoids either (1) or (2)? Do these=20 > restrictions also work if the above crucial code is within a loop (and=20 > hence the inputs to PHIs are the PHIs themself, which is the actual=20 > canonical variant of the lost-copy and swap problems). Hope the above answers this. Using the notation above, every input to an xn PHI always has the form xi. I don't think it's worth having a native SSA form in RTL given that we already have one in gimple. It would just lose some low-level details that are (IMO) important for RTL, and that distinguish RTL from gimple, such as the need for a temporary register in your swap example. Thanks, Richard