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 7F944385781A for ; Wed, 17 Mar 2021 13:27:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7F944385781A 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 49786AC23; Wed, 17 Mar 2021 13:27:27 +0000 (UTC) Date: Wed, 17 Mar 2021 13:27:26 +0000 (UTC) From: Michael Matz To: Richard Biener cc: Thomas Schwinge , GCC Development Subject: Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)' In-Reply-To: Message-ID: References: <87pn00z2st.fsf@euler.schwinge.homeip.net> <87mtv3ywdp.fsf@euler.schwinge.homeip.net> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.5 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 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 13:27:29 -0000 Hello, On Wed, 17 Mar 2021, Richard Biener wrote: > > The walk_gimple functions are intended to be used on the SSA form of > > gimple (i.e. the one that it is in most of the time). > > Actually they are fine to use pre-SSA. Structurally, sure. > They just even pre-SSA distinguish between registers and memory. And that's of course the thing. I probably should have used a different term, but used "SSA rewriting" to name the point where this distinction really starts to matter. Before it a binary gimple statement could conceivably contain a non-register in the LHS (perhaps not right now, but there's nothing that would inherently break with that), and then would include a store that walk_stmt_load_store_addr_ops would "miss". So, yeah, using SSA as name for that was sloppy, it's gimple itself that has the invariant of only registers in binary statements. Ciao, Michael. > That's what gimplification honors as well, in 'zzz = r + r2' all > operands are registers, otherwise GIMPLE requires loads and stores split > into separate stmts not doing any computation. > > It's just less obivous in the dumps (compared to SSA name dumping). > > Richard. > > > And in that it's > > not the case that 'zzz = 1' and 'zzz = r + r2' are similar. The former > > can have memory as the lhs (that includes static variables, or indirection > > through pointers), the latter can not. The lhs of a binary statement is > > always an SSA name. A write to an SSA name is not a store, which is why > > it's not walked for walk_stmt_load_store_addr_ops. > > > > Maybe it helps to look at simple C examples: > > > > % cat x.c > > int zzz; > > void foo(void) { zzz = 1; } > > void bar(int i) { zzz = i + 1; } > > % gcc -c x.c -fdump-tree-ssa-vops > > % cat x.c.*ssa > > foo () > > { > > : > > # .MEM_2 = VDEF <.MEM_1(D)> > > zzz = 1; > > # VUSE <.MEM_2> > > return; > > } > > > > bar (int i) > > { > > int _1; > > > > : > > _1 = i_2(D) + 1; > > # .MEM_4 = VDEF <.MEM_3(D)> > > zzz = _1; > > # VUSE <.MEM_4> > > return; > > > > } > > > > See how the instruction writing to zzz (a global, and hence memory) is > > going through a temporary for the addition in bar? This will always be > > the case when the expression is arithmetic. > > > > In SSA form gimple only very few instruction types can be stores, namely > > calls and stores like above (where the RHS is an unary tree). If you want > > to capture writes into SSA names as well (which are more appropriately > > thought of as 'setting the ssa name' or 'associating the ssa name with the > > rhs value') you need the per-operand callback indeed. But that depends on > > what you actually want to do. > > > > > > Ciao, > > Michael. >