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 2E8DC38582BA; Fri, 8 Jul 2022 15:31:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E8DC38582BA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 918E41FDBD; Fri, 8 Jul 2022 15:31:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1657294310; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NiBqePU7MVBRp859soybyKcj1GtGuyXJPPzOaVQmBoI=; b=kP17kk79nrXKJ/Cjnb/N4vPz1QhAp9K02YVjAaHNAyVqoepedmhcs4uA5c3VLu88WM64yJ YASiPpYLPuQjdKuLP+OoyQKZll6XpmUSqtytn9b4uhWAH5NNbibUl5dNIxwnHhCQoT6bfo HMQByene6WCDpmib5kZhk7Gd53ySfsY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1657294310; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NiBqePU7MVBRp859soybyKcj1GtGuyXJPPzOaVQmBoI=; b=9Ho2Iz8+uac7FS9DpNv5FXfRrOsaM9Eg0cVD8vKCnQ5mIFoY/Oq+kdXtNBVjxEoe6w/HVm 9/ltXfTHMOp52dAg== Received: from suse.cz (unknown [10.100.200.98]) (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 6E73E2C141; Fri, 8 Jul 2022 15:31:50 +0000 (UTC) From: Martin Jambor To: Erick Ochoa Cc: gcc@gcc.gnu.org Subject: Re: Question about speculative make_edge_direct_to_target during LTO/IPA_PASS In-Reply-To: References: User-Agent: Notmuch/0.35 (https://notmuchmail.org) Emacs/28.1 (x86_64-suse-linux-gnu) Date: Fri, 08 Jul 2022 17:31:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Fri, 08 Jul 2022 15:31:53 -0000 Hi Erick,, On Thu, Jul 07 2022, Erick Ochoa wrote: > On Fri, 1 Jul 2022 at 14:48, Martin Jambor wrote: > >> Why so late, why not as part of number 4? >> > Thanks for the feedback. The original reason why the call to > make_edge_direct_to_target was done so late is because of the lack of > function bodies during WPA, summaries with insufficient information (I keep > track of only some information which when access to function bodies is > given during LTRANS I can finally have a cgraph_edge to use as a > parameter), and I am still figuring out things with edge summaries. > > I have a couple of questions here to improve my summaries: > > If I were to call make_edge_direct_to_target during WPA (or number 4) then > I need to have access to the indirect edge during WPA. This is because > make_edge_direct_to_target receives a cgraph_edge as a parameter. In order > to have access to the indirect edge during WPA, I need to generate > summaries which keep track of indirect edges. That is being done and should not be a problem. You just iterate over the list beginning with node->indirect_calls and analyze it like normal edges. > > I think this would be done with edge summaries. Again, my understanding of > edge summaries is incomplete. They are meant to be a generic mechanism to describe calls that is pass-specific, they contain what the author of the pass puts in there. > My understanding is that they contain > information to be transmitted along the edges of the call graph. That is how they are often used but generally speaking they are simply some sort of a description of a call. > However, > the implementation details are what is making it difficult for me to > understand. Unlike cgraph_nodes which can be encoded and decoded, it seems > to me that cgraph_edges have no encoding nor decoding. This makes it > somewhat hard to say that an information belongs to a given edge. I am not sure I understand, you mean the encoding and decoding during streaming? I simply suggest that you do what ipa-fnsummary and IPA-SRA do. The mechanism is quite ugly, improvement in the streaming API would be IMHO desirable, but I guess that is quite outside the scope of your project. > > Looking into ipa-cp / ipa-prop it looks like edge summaries are stored by > first encoding the caller cgraph_node and then iterating over the edges in > the node->callees and node->indirect_calls. However, I know that edges can > be removed. Fortunately, not in between streaming them to disk and then back, so this should not be a concern. > That's why there are edge removal hooks. No, removal hooks are there mainly to deallocate memory that is no longer necessary (plus they are used by reference counting and stuff, but not for streaming consistency). > Shouldn't this affect > the information that is written if an edge was removed somewhere else? > Something that is not explicit, is also that the order in the node->callees > and node->indirect_calls is preserved from the moment the summary is > written to the moment the summary is read. Is this the case? Yes, otherwise the code in place would not work, I guess. > > My understanding is also limited from the fact that ipa-cp does not have a > proper write_summary nor read_summary stages in its own class and instead > ipa-cp's summaries are written and read during ipa-prop. ipa-prop is a file, not a pass. The summaries are generated and written during pass_ipa_fn_summary. The only reason for that is that both IPA-CP and inlining (and now also IPA-modref, I think) use what previously were summaries of the other pass and eventually it made sense to gather and stream them together. > Is this an > implementation detail so that the edge information created for ipa-cp is > propagated correctly during inlining? (Or is there some other explanation > for this?) See above, there are no correctness reasons for this. > Would it also makes sense to write and read my edge summaries at > the same time as ipa-cp's edge summaries? That is difficult to say without knowing what is in your summary and what else you need. If you make heavy use of information gathered by IPA-CP/inlining, then perhaps yes. But some isolation of the individual passes is also good. So for example IPA-SRA has its own node and edge summaries. > I know that the base class > (call_summary) also has virtual methods for removal and duplication of > edges (which should be triggered during inlining / cleaning up of the > callgraph). But somehow the virtual methods ::remove and ::duplicate seem > different to me from the callbacks which need to be registered in the > IPA_PASSes. I'm not sure I understand. Do you mean hooks like add_edge_removal_hook of the symbol_table class? Summaries use these internally to implement the virtual methods you describe but there is nothing compulsory about the hooks. I also do not see what difference in between the two you find troubling. > Again, why would one need to write and read ipa-cp's summaries > during ipa-prop if these callbacks exist which are triggered when summaries > need to be updated? The summary updating callbacks exist because passes run one after each other and when one modifies the call-graph, the others often need to update their own internal data structures, which summaries are. The division of code between ipa-prop.cc and ipa-cp.cc does not really matter here. Martin