From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 773533973074 for ; Fri, 27 Nov 2020 15:56:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 773533973074 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=matz@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4AB37ABD7; Fri, 27 Nov 2020 15:56:38 +0000 (UTC) Date: Fri, 27 Nov 2020 15:56:38 +0000 (UTC) From: Michael Matz To: Richard Sandiford cc: Jeff Law via Gcc-patches Subject: Re: [00/23] Make fwprop use an on-the-side RTL SSA representation In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 15:56:40 -0000 Hello, On Thu, 26 Nov 2020, Richard Sandiford via Gcc-patches wrote: > >> The aim is only to provide a different view of existing RTL instructions. > >> Unlike gimple, and unlike (IIRC) the old RTL SSA project from way back, > >> the new framework isn't a “native” 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 “hidden” in the phi node. > > Hmm, I'm trying to parse what the last phrase means.  Does it mean that > > the "hidden copy" problem for out-of-ssa is avoided?  And if so, how is > > that maintained over time.  Things like copy-prop will tend to introduce > > those issues even if they didn't originally exist. > > 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. > > 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. 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 to the below would become obvious, sorry if so :) ) So, you're saying that in your implementation the operands of PHIs can be PHIs and real defs. Further you say nothing about any restriction in RTL instruction moving and/or propagation. So, then let's start with one of the prime examples of SSA deconstruction problems, the lost swap, and how it comes to be: we start with a swap: x = ..., y = ... if (cond) tmp=x, x=y, y=tmp (1) into SSA: x0 = ..., y0 = ... if (cond) tmp = x0, x1=y0, y1=tmp; x2 = PHI(x0,x1), y2 = PHI(y0,y1) (2) copy-prop: x0 = ..., y0 = ... if (cond) ; x2 = PHI(x0,y0), y2 = PHI(y0,x0) Now you're also saying that the SSA form can simply be deleted without any consideration of the parallel copy nature, i.e. no real out-of-ssa phase. In the above example that would lead to wrong code, so that can't be it. So what in your representation avoids either (1) or (2)? Do these restrictions also work if the above crucial code is within a loop (and hence the inputs to PHIs are the PHIs themself, which is the actual canonical variant of the lost-copy and swap problems). Ciao, Michael.