From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 91A963858C27 for ; Tue, 8 Feb 2022 07:20:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 91A963858C27 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 824AE1F37C; Tue, 8 Feb 2022 07:20:21 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 64FC5A3B84; Tue, 8 Feb 2022 07:20:21 +0000 (UTC) Date: Tue, 8 Feb 2022 08:20:21 +0100 (CET) From: Richard Biener To: Joseph Myers cc: gcc-patches@gcc.gnu.org, Jakub Jelinek , matz@suse.de Subject: Re: [PATCH 1/4][RFC] middle-end/90348 - add explicit birth In-Reply-To: Message-ID: References: <20220204134914.25D7C13A96@imap2.suse-dmz.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 08 Feb 2022 07:20:24 -0000 On Mon, 7 Feb 2022, Joseph Myers wrote: > On Fri, 4 Feb 2022, Richard Biener via Gcc-patches wrote: > > > This adds explicit variable birth CLOBBERs in an attempt to fix > > PR90348 and duplicates. The birth / death CLOBBER pairs are > > used to compute liveness and conflicts for stack variable > > coalescing where the lack of an explicit birth but instead > > use of first mention causes misrepresentation of variable life > > ranges when optimization moves the first mention upwards the > > original birth point at the variables bind expression start. > > I'm not clear on exactly where you consider a variable to be born, but > note that non-VLA C variables have a lifetime that starts at the beginning > of their block, not at their declaration: it's valid to jump backward from > after the declaration to before it and then access the variable via a > pointer, or jump forward again over the declaration and access it by name. > (Most programs of course don't do that sort of thing.) Oh, interesting. So the following is valid int foo(int always_true_at_runtime) { { int *p; if (always_true_at_runtime) goto after; lab: return *p; after: int i = 0; p = &i; if (always_true_at_runtime) goto lab; } return 0; } For the implementation I considered starting lifetime at a DECL_EXPR if it exists and otherwise at the start of the BIND_EXPR. Note the complication is that control flow has to reach the lifetime-start clobber before the first access. But that might also save us here, since for the example above 'i' would be live via the backedge from goto lab. That said, the existing complication is that when the gimplifier visits the BIND_EXPR it has no way to know whether there will be a following DECL_EXPR or not (and the gimplifier notes there are cases a DECL_EXPR variable is not in a BIND_EXPR). My plan is to compute this during one of the body walks the gimplifier performs before gimplifying. Another complication is that at least the C frontend + gimplifier combination for switch (i) { case 1: int i; break; } will end up having the BIND_EXPR mentioning 'i' containing the case label, so just placing the birth at the BIND will make it unreachable as i = BIRTH; case_label_for_1: ... conveniently at least the C frontend has a DECL_EXPR for 'i' which avoids this and I did not find a way (yet) in the gimplifier to rectify this when gimplifying switches. So there's still work to do but I think that starting the lifetime at a DECL_EXPR if it exists is the way to go? Richard.