From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by sourceware.org (Postfix) with ESMTPS id 54627385B83D for ; Thu, 7 Jul 2022 13:17:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54627385B83D Received: by mail-pg1-f175.google.com with SMTP id o18so17287073pgu.9 for ; Thu, 07 Jul 2022 06:17:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j/1dE3TePXnjYNjoZG2nW94i27CHGYmWkrTTWSVWIuA=; b=UWzc6/SuaHRUfGpSYIx6y86u1AaJ2jq7pke/4DeRADp97K4XsaGC5xdUuLuobIYTf7 fNNkBPR/Q6NdIivrDzItdKU8pvv9uaX1g7ZvnMVaI6kYjCku/UIWjM58ckHciip18OTk MAQTcupuWRQJwLoC3fSelP3O6Nf27J3jjO++BhjEsnqLSq7BfmqEgmCTZ5G5oNpUxPNA 66KeWpHualNWQ5aBUeFxMkHUS2EILH10bhdroBDhIwgMU5EYnXR03jBm2/6YZvR99xvf ahUk7nfIjvs+JtyRbDNS4d0GpHUXCGdGb7635WFyAKWdiWfK8EuvmW7b875S9BGLBp25 +neA== X-Gm-Message-State: AJIora9rUuqI9CcOhtgqpSi+e4Jq8S34fTSrArD0pGFNXJuvZg+ibS9D pAynQvxLVQ9kggkpa+OddsaGqJMX5CIgfA== X-Google-Smtp-Source: AGRyM1so1s5FayrhFWnlj5lI9Z/5Cl+472uqSQgR8ooTxTJTjn/SwoOEFKbTw58+dzGuhvaOYyyyxw== X-Received: by 2002:a17:90b:1b4d:b0:1ec:c42a:7eb5 with SMTP id nv13-20020a17090b1b4d00b001ecc42a7eb5mr5140480pjb.122.1657199834875; Thu, 07 Jul 2022 06:17:14 -0700 (PDT) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com. [209.85.210.173]) by smtp.gmail.com with ESMTPSA id d3-20020a17090a2a4300b001ef8a6836e3sm8502135pjg.55.2022.07.07.06.17.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jul 2022 06:17:14 -0700 (PDT) Received: by mail-pf1-f173.google.com with SMTP id o12so5754304pfp.5 for ; Thu, 07 Jul 2022 06:17:14 -0700 (PDT) X-Received: by 2002:a17:90b:893:b0:1ef:8342:e17b with SMTP id bj19-20020a17090b089300b001ef8342e17bmr5155490pjb.159.1657199833656; Thu, 07 Jul 2022 06:17:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erick Ochoa Date: Thu, 7 Jul 2022 15:20:33 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Question about speculative make_edge_direct_to_target during LTO/IPA_PASS To: Martin Jambor Cc: gcc@gcc.gnu.org X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 07 Jul 2022 13:17:18 -0000 On Fri, 1 Jul 2022 at 14:48, Martin Jambor wrote: > Why so late, why not as part of number 4? > Hi Martin, 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. I think this would be done with edge summaries. Again, my understanding of edge summaries is incomplete. My understanding is that they contain information to be transmitted along the edges of the call graph. 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. 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. That's why there are edge removal hooks. 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? 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. 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?) Would it also makes sense to write and read my edge summaries at the same time as ipa-cp's 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. 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? Thanks! -Erick