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 ED16E384A029 for ; Tue, 1 Dec 2020 00:03:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ED16E384A029 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 A75D9ABD2; Tue, 1 Dec 2020 00:03:55 +0000 (UTC) Date: Tue, 1 Dec 2020 00:03:55 +0000 (UTC) From: Michael Matz To: Jeff Law cc: Jeff Law via Gcc-patches , richard.sandiford@arm.com Subject: Re: [00/23] Make fwprop use an on-the-side RTL SSA representation In-Reply-To: <97fbb734-bd83-1d1b-6b80-372f2743d76d@redhat.com> Message-ID: References: <97fbb734-bd83-1d1b-6b80-372f2743d76d@redhat.com> 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: Tue, 01 Dec 2020 00:03:58 -0000 Hello, On Mon, 30 Nov 2020, Jeff Law wrote: > >> 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) > > 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 “native” SSA form: it's just using SSA > > constructs to represent dataflow in normal RTL. > It appears that the PHI arguments have to be different instances of the > result.  So the case above can't happen, which helps, but I'm not sure > it's necessarily sufficient to avoid all the problems in this space. > IIRC you can get into a similar scenario by transformations that result > in overlapping lifetimes for different instances of the same object.  > They didn't necessarily overlap when the SSA form was created, but may > after things like CSE or copy propagation. I think the reasoning why this can't (or should not) happen is the following: if different instances of the same objects (say, one before, one after a modification) exist, they must necessarily be stored in different pseudos (otherwise the RTL transformation itself was already invalid), and that causes them to be invalid operands of the same PHI node. Ala: input: regA = .... /1 use1(regA) /2 regA += ... /3 use2(regA) /4 let's try creating different instances of regA (from point 2 and 4) that overlap, e.g. by swapping insns 2 and 3. We _have_ to rename regA from insn 3 into a new pseudo, otherwise the uses of 2 and 4 can't be differentiated anymore, so: regA = .... /1 regA' = regA regA' += .... /3' use1(regA) /2 use2(regA') /4' So if Richards model constrains the pseudo PHI nodes such that regA and regA' can't be operands of one, that might solve the issue, as both the lost copy and the swap problem need overlaps of different values to occur. > The fact that passes don't directly manipulate the PHIs definitely helps > as well.  But I've still got some reading to do in this space to refresh > my memory of the issues. AFAIU Richards approach is more comparable to factored def-use chains than to real SSA, which might indeed have no issues, though I then think the problem moves into keeping _those_ consistent with the real instruction stream as it changes. Ciao, Michael.