This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 4/4] Data structure is used for inline_summary struct.
- From: Martin Jambor <mjambor at suse dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Martin LiÅka <mliska at suse dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 18 Nov 2014 18:40:22 +0100
- Subject: Re: [PATCH 4/4] Data structure is used for inline_summary struct.
- Authentication-results: sourceware.org; auth=none
- References: <cd4c62522f43eb2d2ad92769431e91c8d8bd15bc dot 1415888515 dot git dot mliska at suse dot cz> <0747c9874be8f00250182794f2eb38d021464046 dot 1415888515 dot git dot mliska at suse dot cz> <20141113160431 dot GG11013 at kam dot mff dot cuni dot cz> <54660D21 dot 3030200 at suse dot cz> <20141114160643 dot GF12658 at kam dot mff dot cuni dot cz> <20141114180708 dot GP29726 at virgil dot suse> <20141114195910 dot GC6818 at kam dot mff dot cuni dot cz> <20141118123921 dot GV29726 at virgil dot suse> <20141118153900 dot GA12650 at kam dot mff dot cuni dot cz>
Hi,
On Tue, Nov 18, 2014 at 04:39:00PM +0100, Jan Hubicka wrote:
> > On Fri, Nov 14, 2014 at 08:59:10PM +0100, Jan Hubicka wrote:
> > > > >
> > > > > > b) with GTY, we cannot call destructor
> > > > >
> > > > > Everything in symbol table is expecitely memory managed (i.e. enver left
> > > > > to be freed by garbage collector). It resists in GTY only to allow linking
> > > > > garbage collected object from them and to get PCH working.
> > > > >
> > > >
> > > > Well, if I understand the intent correctly, summaries are for stuff
> > > > that is not in the symbol table. For example jump functions are a
> > > Correct.
> > > > vector of structures possibly containing trees, so everything has to
> > > > be in garbage collected memory.
> > > >
> > > > When an edge is removed, it is necessary to be notified about it
> > > > immediately, for example to decrement rdesc_refcount (you might argue
> > > > that that should be done in a separate hook and not from within a
> > > > summary class but then you start to rely on hook invocation ordering
> > > > so I think it is better to eventually use the summaries for it too).
> > >
> > > I do not see why ctors/dtors can not do the reference counting. In fact
> > > this is how refcounting is done usually anyway?
> > >
> >
> > Well, when there is no garbage collection involved then yes, that is
> > how you normally do it but in the GC case, there is the question of
> > what is the appropriate time to call destructor on garbage collected
> > data (like jump functions)?
>
> I still fail to see problem here. Summaries are explicitly managed- they are
> constructed at summary construction time or when new callgarph node is
> introduced/duplicated. They are destroyed when callgarph node is destroyed or
> whole summary is ddestroyed. It is job of the summary datastructure to call
> proper ctors/dtors, not job of garbage collector that provides the underlying
> memory management.
I do not think that all summaries (in the meaning of a description of
one particular symbol table node or call graph edge) are explicitely
managed. For example ipa_edge_args or ipa_agg_replacement_value
(which my alignment patch changes to ipcp_transformation_summary) are
allocated in GC memory because they contain trees.
>
> If you have datastructure that points to something that is not
> explicitly managed (i.e. tree expression), you just can not have
> non-trivial constructor on that datastructure, because that is freed
> transparently by gty that don't do destruction...
I admit to not being particularly bright today but that seems to be
exactly my point.
Martin