* Question on cgraph_edge::call_stmt during LTO @ 2022-05-20 12:43 Erick Ochoa 2022-05-20 22:13 ` Martin Jambor 0 siblings, 1 reply; 4+ messages in thread From: Erick Ochoa @ 2022-05-20 12:43 UTC (permalink / raw) To: gcc Hi, I'm working on a pass that looks into the estimated values during ipa-cp and stores them for a later analyses/pass. I would like to store the real arguments' estimates in a cgraph_edge::call_stmt or somewhere else that makes similar sense. (Note, this is different from the formal parameters' estimates which can be found in the lattice print out of ipa-cp). I have already added a new field in the definition of gimple_call, made sure that this field is streamed-out, streamed-in, and set the values during ipa-cp. However, I am having problems with what I believe is the inlining and cloning of cgraph_nodes. Whenever a cgraph_node is inlined or cloned, I would need to copy this information and update if necessary. At the moment, when I am trying to read the information during a late SIMPLE_IPA_PASS, the information is simply not there. I believe that the cgraph_edge is not the same since during ipa-cp the callee has been specialized and during ipa-inline the caller has been inlined to a different caller. Also, for some cgraph_edge's the call_stmt is NULL. I believe this can also be due to inlining, but I am not sure. Can someone point out a good way to keep this information in sync with the creation and deletion of cgraph_edges? Maybe an alternative to cgraph_edge::call_stmt? Thanks! -Erick ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question on cgraph_edge::call_stmt during LTO 2022-05-20 12:43 Question on cgraph_edge::call_stmt during LTO Erick Ochoa @ 2022-05-20 22:13 ` Martin Jambor 2022-06-02 7:45 ` Erick Ochoa 0 siblings, 1 reply; 4+ messages in thread From: Martin Jambor @ 2022-05-20 22:13 UTC (permalink / raw) To: Erick Ochoa, gcc Hello, On Fri, May 20 2022, Erick Ochoa via Gcc wrote: > Hi, > > I'm working on a pass that looks into the estimated values during ipa-cp > and stores them for a later analyses/pass. I would like to store the real > arguments' estimates in a cgraph_edge::call_stmt or somewhere else that > makes similar sense. (Note, this is different from the formal parameters' > estimates which can be found in the lattice print out of ipa-cp). the statement is not the right place to store such pass-specific information, for reasons you described and more (especially simple memory use efficiency). Instead they should be placed into an "edge summary" (also sometimes called "call summary"), a structure similar to ipa_edge_args_sum (in ipa-prop.h and ipa-prop.cc). Unlike ipa_edge_args_sum, which is allocated at analysis phase, then streamed out and in in case of LTO, and used thrown away during the IPA analysis phase, your summary would need to be allocated at IPA analysis time, then streamed out in ipcp_write_transformation_summaries, streamed in in ipcp_read_transformation_summaries so that they can be used in the transformation phase. Usually a simple implementation of the duplication hook of an edge summary is enough for the data to survive cloning and inlining and the like. Martin ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question on cgraph_edge::call_stmt during LTO 2022-05-20 22:13 ` Martin Jambor @ 2022-06-02 7:45 ` Erick Ochoa 2022-06-14 16:41 ` Martin Jambor 0 siblings, 1 reply; 4+ messages in thread From: Erick Ochoa @ 2022-06-02 7:45 UTC (permalink / raw) To: Martin Jambor; +Cc: gcc Hi Martin, Thanks for the tips! I have implemented an edge summary which: * is allocated at IPA analysis phase * streamed out in ipcp_write_transformation_summaries * streamed in in ipcp_read_transformation_summaries However, before the implementation of this edge summary we had another mechanism of propagating the information all the way until it was used in a SIMPLE_IPA_PASS executed after all LGEN stages were finished (after all_regular_ipa_passes). After changing the implementation to use edge summaries, I find that the information is conserved during inlining (the duplication hook prints out the new edges that gets formed via inlining with the correct information), however it is not found in the SIMPLE_IPA_PASS that gets executed after all_regular_ipa_passes. What is perhaps more interesting is that if I run with -fno-ipa-pure-const and no -fno-ipa-modref, I can still see the cgraph_nodes and edges of the inlined methods, along with the information needed. But not in the ones that have been inlined. I believe this could be just that when these options are disabled, cgraph_nodes might not be reclaimed. I understand that there are many differences between SIMPLE_IPA_PASSes and regular IPA_PASSes, but at the moment I am unsure how to narrow down my search for a fix. Is this something that could be caused by: * memory management: (I am not familiar with the memory management in GCC and it is a bit difficult to understand.) I have removed the bodies of the my_edge_summary::remove (cgraph_edge*) and my_edge_summary::remove (cgraph_edge *, my_edge_summary_instance *) so I don't think this might be it. However, the class my_edge_summary still copies some of the structure in the other transformation summaries, so there is a macro GTY((for_user)) in the class declaration and the information is stored in a vec <int, va_gc> *my_info. * missing implementation details in the duplicate functions: Looking at ipa_edge_args_sum_t::duplicate, it is a relatively complex function. I also noticed that it does something else when the dst->caller has been inlined. Should I also update the cgraph_edge that disappears when dst->caller is inlined to its caller? * something else? Any direction is greatly appreciated! Many thanks! -Erick On Sat, 21 May 2022 at 00:13, Martin Jambor <mjambor@suse.cz> wrote: > Hello, > > On Fri, May 20 2022, Erick Ochoa via Gcc wrote: > > Hi, > > > > I'm working on a pass that looks into the estimated values during ipa-cp > > and stores them for a later analyses/pass. I would like to store the real > > arguments' estimates in a cgraph_edge::call_stmt or somewhere else that > > makes similar sense. (Note, this is different from the formal parameters' > > estimates which can be found in the lattice print out of ipa-cp). > > the statement is not the right place to store such pass-specific > information, for reasons you described and more (especially simple > memory use efficiency). > > Instead they should be placed into an "edge summary" (also sometimes > called "call summary"), a structure similar to ipa_edge_args_sum (in > ipa-prop.h and ipa-prop.cc). Unlike ipa_edge_args_sum, which is > allocated at analysis phase, then streamed out and in in case of LTO, > and used thrown away during the IPA analysis phase, your summary would > need to be allocated at IPA analysis time, then streamed out in > ipcp_write_transformation_summaries, streamed in in > ipcp_read_transformation_summaries so that they can be used in the > transformation phase. > > Usually a simple implementation of the duplication hook of an edge > summary is enough for the data to survive cloning and inlining and the > like. > > Martin > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question on cgraph_edge::call_stmt during LTO 2022-06-02 7:45 ` Erick Ochoa @ 2022-06-14 16:41 ` Martin Jambor 0 siblings, 0 replies; 4+ messages in thread From: Martin Jambor @ 2022-06-14 16:41 UTC (permalink / raw) To: Erick Ochoa; +Cc: gcc Hello Erick, sorry for a late reply, I've been recovering from an injury recently. On Thu, Jun 02 2022, Erick Ochoa wrote: > Hi Martin, > > Thanks for the tips! I have implemented an edge summary which: > > * is allocated at IPA analysis phase > * streamed out in ipcp_write_transformation_summaries > * streamed in in ipcp_read_transformation_summaries > > However, before the implementation of this edge summary we had another > mechanism of propagating the information all the way until it was used in a > SIMPLE_IPA_PASS executed after all LGEN stages were finished (after > all_regular_ipa_passes). After changing the implementation to use edge > summaries, I find that the information is conserved during inlining (the > duplication hook prints out the new edges that gets formed via inlining > with the correct information), however it is not found in the > SIMPLE_IPA_PASS that gets executed after all_regular_ipa_passes. I have discussed your situation with Honza and we could not think of a reason why this is happening to you. Summaries have destructors, so we suggest you put a breakpoint in there and see where your summaries get deallocated. > > What is perhaps more interesting is that if I run with -fno-ipa-pure-const > and no -fno-ipa-modref, I can still see the cgraph_nodes and edges of the > inlined methods, along with the information needed. But not in the ones > that have been inlined. I believe this could be just that when these > options are disabled, cgraph_nodes might not be reclaimed. In a late SIMPLE_IPA_PASS? That is really weird, the inlining transformation code quite clearly removes those. How do you even get at these nodes and edges, by traversing the call graph? If not, you might indeed be looking at stale data structures. > I understand that there are many differences between SIMPLE_IPA_PASSes and > regular IPA_PASSes, but at the moment I am unsure how to narrow down my > search for a fix. Is this something that could be caused by: > > * memory management: (I am not familiar with the memory management in GCC > and it is a bit difficult to understand.) I have removed the bodies of the > my_edge_summary::remove (cgraph_edge*) and my_edge_summary::remove > (cgraph_edge *, my_edge_summary_instance *) so I don't think this might be > it. However, the class my_edge_summary still copies some of the structure > in the other transformation summaries, so there is a macro GTY((for_user)) > in the class declaration and the information is stored in a vec <int, > va_gc> *my_info. > * missing implementation details in the duplicate functions: Looking at > ipa_edge_args_sum_t::duplicate, it is a relatively complex function. I also > noticed that it does something else when the dst->caller has been inlined. > Should I also update the cgraph_edge that disappears when dst->caller is > inlined to its caller? > * something else? > You probably do not need that complexity. ipa_edge_args_sum_t::duplicate does kind of reference counting so that it can then estimate what references should look like after cloning and inlining, and speculation and speculation-resolutions make this complex. Unless you need to track something similar or treat speculative edges especially for some reason, you can just copy your data and be done with it. > Any direction is greatly appreciated! Sorry if I did not help much and good luck. Martin > > On Sat, 21 May 2022 at 00:13, Martin Jambor <mjambor@suse.cz> wrote: > >> Hello, >> >> On Fri, May 20 2022, Erick Ochoa via Gcc wrote: >> > Hi, >> > >> > I'm working on a pass that looks into the estimated values during ipa-cp >> > and stores them for a later analyses/pass. I would like to store the real >> > arguments' estimates in a cgraph_edge::call_stmt or somewhere else that >> > makes similar sense. (Note, this is different from the formal parameters' >> > estimates which can be found in the lattice print out of ipa-cp). >> >> the statement is not the right place to store such pass-specific >> information, for reasons you described and more (especially simple >> memory use efficiency). >> >> Instead they should be placed into an "edge summary" (also sometimes >> called "call summary"), a structure similar to ipa_edge_args_sum (in >> ipa-prop.h and ipa-prop.cc). Unlike ipa_edge_args_sum, which is >> allocated at analysis phase, then streamed out and in in case of LTO, >> and used thrown away during the IPA analysis phase, your summary would >> need to be allocated at IPA analysis time, then streamed out in >> ipcp_write_transformation_summaries, streamed in in >> ipcp_read_transformation_summaries so that they can be used in the >> transformation phase. >> >> Usually a simple implementation of the duplication hook of an edge >> summary is enough for the data to survive cloning and inlining and the >> like. >> >> Martin >> ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-06-14 16:41 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-20 12:43 Question on cgraph_edge::call_stmt during LTO Erick Ochoa 2022-05-20 22:13 ` Martin Jambor 2022-06-02 7:45 ` Erick Ochoa 2022-06-14 16:41 ` Martin Jambor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).