Re: [PATCH] PR/66760, ipa-inline-analysis.c compile-time hog

[Richard Biener <richard dot guenther at gmail dot com>]

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