Re: Question about speculative make_edge_direct_to_target during LTO/IPA_PASS

[Erick Ochoa <eochoa@gcc.gnu.org>]

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