This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR/66760, ipa-inline-analysis.c compile-time hog
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>, Paolo Bonzini <pbonzini at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Mon, 13 Jul 2015 15:45:42 +0200
- Subject: Re: [PATCH] PR/66760, ipa-inline-analysis.c compile-time hog
- Authentication-results: sourceware.org; auth=none
- References: <1436737195-21165-1-git-send-email-bonzini at gnu dot org> <20150713115509 dot GG1819 at virgil dot suse dot cz> <55A3AB87 dot 3000606 at redhat dot com> <20150713123409 dot GH1819 at virgil dot suse dot cz> <55A3B35B dot 1030800 at gnu dot org> <20150713133050 dot GI1819 at virgil dot suse dot cz>
On Mon, Jul 13, 2015 at 3:30 PM, Martin Jambor <mjambor@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