From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56645 invoked by alias); 6 Apr 2015 13:57:55 -0000 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 Received: (qmail 56632 invoked by uid 89); 6 Apr 2015 13:57:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f175.google.com Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 06 Apr 2015 13:57:53 +0000 Received: by obbfy7 with SMTP id fy7so41079050obb.2 for ; Mon, 06 Apr 2015 06:57:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.116.130 with SMTP id jw2mr18811674obb.48.1428328671898; Mon, 06 Apr 2015 06:57:51 -0700 (PDT) Received: by 10.202.229.72 with HTTP; Mon, 6 Apr 2015 06:57:51 -0700 (PDT) In-Reply-To: <20150403184915.GS21276@atrey.karlin.mff.cuni.cz> References: <20150312102706.GL27860@msticlxl57.ims.intel.com> <20150319083455.GD64546@msticlxl57.ims.intel.com> <20150402170115.GB21276@atrey.karlin.mff.cuni.cz> <20150403184915.GS21276@atrey.karlin.mff.cuni.cz> Date: Mon, 06 Apr 2015 13:57:00 -0000 Message-ID: Subject: Re: [CHKP, PATCH] Fix LTO cgraph merge for instrumented functions From: Ilya Enkovich To: Jan Hubicka Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00190.txt.bz2 2015-04-03 21:49 GMT+03:00 Jan Hubicka : >> Assembler name of instrumented function is a transparent alias of >> original function's name. Alias chains are not taken into account by >> analysis. Thus we see no conflict between instrumented function's name >> and a variable name but emit them with the same assembler name. To >> detect name conflict I keep original function node alive. > > Hmm, so lets see if I understand your situation. You always have transparent alias TA > and function F connected by IPA_REF_CHKP and because TA is represented as thunk > you also have a fake call from TA to F? > > I do not understand how you can miss the link these days. I extended lto-cgraph to > always keep thunk and its target in every unit that reffers to thunk. That should > solve you problem? How IPA_REF_CHKP can link get lost? References are not streamed out for nodes which are referenced in a partition but don't belong to it ('continue' condition in output_refs loop). > > I suppose we still need to > 1) write_symbol and lto-symtab should know that transparent aliases are not real > symbols and ignore them. We have predicate symtab_node::real_symbol_p, > I suppose it should return true. > > I think cgraph_merge and varpool_merge in lto-symtab needs to know what to do > when merging two symbols with transparent aliases. > 2) At some point we need to populate transparent alias links as discussed in the > other thread. > 3) For safety, I guess we want symbol_table::change_decl_assembler_name to either > sanity check there are no trasparent alias links pointing to old assembler > names or update it. Wouldn't search for possible referring via transparent aliases nodes be too expensive? > 4) I think we want verify_node to check that transparent alias links and chkp points > as intended and only on those symbols where they need to be > > There is also logic in lto-partition to always insert alias target >> > OK, so you have the chkp references that links to instrumented_version. >> > You do not stream them for boundary symbols but for some reason they are needed, >> > but when you can end up with wrong CHKP link? >> >> Wrong links may appear when cgraph nodes are merged. > > I see, I think you really want to fix these at merging time as sugested in 1). > In this case even the node->instrumented_version pointer may be out of date and > point to a node that lost in merging? node->instrumented_version is redirected and never points to lost symbol. But during merge we may have situations when (node->instrumented_version->instrumented_version != node) because of multiple not merged (yet) symbols referencing the same merged target. Thanks, Ilya > > Honza >> >> Thanks >> Ilya