On Fri, 1 Jul 2022 at 14:48, Martin Jambor <mjam...@suse.cz> 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
