From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id DB52B385780C for ; Fri, 29 Apr 2022 09:52:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DB52B385780C Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id C09E9210DE; Fri, 29 Apr 2022 09:52:37 +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 B905D2C141; Fri, 29 Apr 2022 09:52:37 +0000 (UTC) Date: Fri, 29 Apr 2022 11:52:37 +0200 (CEST) From: Richard Biener To: Jakub Jelinek cc: Jeff Law , gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [PATCH] alias: Fix -fcompare-debug issues caused by compare_base_symbol_refs [PR105415] In-Reply-To: Message-ID: References: <40s7492-n890-1p16-p649-3936sp85qo89@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP 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: Fri, 29 Apr 2022 09:52:40 -0000 On Fri, 29 Apr 2022, Jakub Jelinek wrote: > On Fri, Apr 29, 2022 at 11:32:15AM +0200, Richard Biener wrote: > > I think that's reasonable (we indeed shouldn't create a varpool node > > here). I do think that we eventually want to retain removed nodes > > but mark them so. In fact any debug references will be thrown away > > because of this anyway. > > > > So I wonder if we can instead simply do if (!x_node) return 0;? > > I had that in my first version, but after finding out that it triggers > so often for the constant pool decls I thought better to just use > x_decl in that case instead of x_node->decl. > I must say I'm unsure if constant pool decls always stay out of section > anchors or if they can be put there too. > > > The question is also why sched does any queries for debug-insns, > > does it merely reset them based on the answer? That said, > > it would be nice to be able to assert that x_node is not NULL > > and catch this in the callers somehow. > > Unfortunately, several layers of callers don't really know it is for debug > insn. And the touched code is solely for the section anchors, so e.g. just > checking symtab_node::get (decl) on all mentioned decls when we perhaps can > see if it is debug insn or not would be quite costly and we wouldn't know > if the other reference is anchored. We might want to reset debug stmts at the time we RTL expand them if referred symbols have no cgraph node? As said, ->get () instead of ->get_create () is obviously OK but the way we deal with the fallout is a bit suspicious there IMHO. Richard.