From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3110 invoked by alias); 16 Jan 2013 10:24:44 -0000 Received: (qmail 3097 invoked by uid 22791); 16 Jan 2013 10:24:43 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jan 2013 10:24:32 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 6F6AC5422E9; Wed, 16 Jan 2013 11:24:28 +0100 (CET) Date: Wed, 16 Jan 2013 10:24:00 -0000 From: Jan Hubicka To: Alexandre Oliva Cc: Richard Biener , gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [PR libmudflap/53359] don't register symbols not emitted Message-ID: <20130116102428.GD5949@kam.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg00835.txt.bz2 > No, the bug is that we're registering something because at an earlier > point (when we emitted checks) there were references to it. The > references were all optimized away, we correctly decided (elsewhere) the > object was not referenced, and we removed it from the symbol table, but > mudflap still wants to register it because it pays no attention to that > decision. > > This is the reason why I believe the patch I proposed initially is the > correct fix. Now, can you please tell me why you believe this diagnosis > is incorrect, or why the fix for the diagnosed problem is incorrect, to > the point of proposing alternate (faulty) approaches? > > > I suppose instead of asking for TREE_ASM_WRITTEN you may want to look > > at DECL_RTL (which should be set for all referenced decls, whether > > external or not). > > I'm pretty sure the optimized-away objects that we do NOT want to > register had DECL_RTL set, but I'm not exactly excited about double > checking it without at least a hint of an explanation on what seems to > be wrong with the proposed patch. Well, from symtab point of view, the early mudflap pass (that is collecting vars it wants to later reffer to) should - either build the references to them early and produce the constructor referencing them early. Then symtab has full information about what is going to be output and everything works well. This is what I slowly did to many parts of compiler, like C++, EH or OBJC interfaces that used to be output late. - of if there is good reason to delay this till end of the compilation it should 1) force them to be output when seeing early so they are not optimized away 2) check if they are optimized away or not. 2) has the obvious advantage that unused vars are not going to be output just for sake of checking code. For 2) the symtab_get_node test seems resonable to me. It is what dwarf2out does, too. We keep nodes for external vars that are refereed but we remove all optimized out nodes. At this point TREE_ASM_WRITTEN should have pretty much same info with two differences 1) for const_decls in constant pool varpool is still not representing things accurately 2) I would like to eventually get rid of TREE_ASM_WRITTEN in favor of test in symtab (in 4.9 I will unify the var/function flags in symtab to make this easier and I will add noes for labels since these are also needed for acurate partitioning. I would like to also eventually get rid of on-the-side constant pool but as explained in the HP PR it is not trivial, given how constant pool is tied to rtl codegen and machine reorg for some targets). So I am not really keen for new uses of this flag appearing. I believe CONST_DECLs are not a concern here. Otherwise I guess TREE_ASM_WRITTEN is good hack for 4.8 modulo the fact htat some FEs still trick with it. Honza