On Mon, Jul 13, 2015 at 3:30 PM, Martin Jambor <mjam...@suse.cz> wrote: > On Mon, Jul 13, 2015 at 02:47:23PM +0200, Paolo Bonzini wrote: >> >> >> On 13/07/2015 14:34, Martin Jambor wrote: >> > You might want to use Martin's shiny new >> > function_summary class in symbol-summary.c. That is a mechanism >> > specifically designed to append to a cgraph_node information specific >> > to an optimization pass (or two, as ipa-cp and ipa-inline already both >> > use a few of them). Unfortunately, the class is not very well >> > documented but you should be able to figure out how to use it from >> > other code using them. >> > >> > If you then always deallocate everything there at the end of >> > ipa-inline analysis, you'll get exactly the right life-time for the >> > data. >> >> Good. I might as well merge func_body_info and ipa_node_params then, so >> I already have ipa_node_params_sum. WDYT? > > Well, perhaps but I am not so sure. I have made a conscious decision > to make func_body_info a separate structure and not a part of > ipa_node_params exactly because of their different life-times. > > func_body_info is something only used during intra-procedural stage of > IPA analysis and should be thrown away as soon as it is over. > > ipa_node_params is a structure which contains results of that > analysis, which are streamed to disk during LTO and then read back for > the actual intEr-procedural propagation of information. Yes, it also > contains quite a few fields that are used only during the IPA stage > and so perhaps a few more bits used only during the intra-stage might > be OK too. But Honza recently told me the ipa-structures are > beginning to show in memory footprint of LTOing Firefox, so allocating > more unused memory for each and every function in Firefox and all its > clones is not really such a good idea. > > I also tend to think that coding the deallocation is going to be > easier for you if you just use another summary. For an > analysis-stage-only summary, you do not need to implement any of the > hooks (i.e. insert, remove, duplicate), for example. Those should > never happen during intraprocedural phase, or so I believe :-), so > just put gcc_unreachable into them and that should be it. > > I'm sorry for making this so complicated :-)
It would be nice to have a patch that can be backported to the GCC 5 branch as well. We can improve this on trunk as followup,no? Richard. > Martin