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: Fri, 14 Nov 2014 19:07:08 +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>
On Fri, Nov 14, 2014 at 05:06:44PM +0100, Jan Hubicka wrote:
> > >
> > >In a way I would like to see these to be methods of the underlying type rather than
> > >virtual methods of the summary, becuase these are operations on the data themselves.
> > >I was thinking to model these by specual constructor and copy constructor
> > >(taking the extra node pointer parameters) and standard destructor. I am not sure this
> > >would be more understandable this way?
> >
> > Motivation for this implementation is:
> > a) it's useful to have an access to cgraph_node that is associated with a sumary
>
> Yep, one would have node addition
> ctor (symtab_node *); (or cgraph/varpool nodes for cgraph/varpool annotations)
> that would default to ctor for implementations that do not care about node.
> And node duplication ctor
> ctor (summary &, symtab_node *, symtab_node *)
> that would default to copy constructor for data that do not need to be copied.
>
> I would say that main advantage (in addition to have a way to provide resonable
> defaults) is to make ctors/dtors of the embedded classes working well, so one can
> for example embedd pointer_map and not care about its construction/destruction.
It was actually me who suggested virtual methods instead of
constructors. My idea was to make the summaries very light-weight and
usable even for simple types. For example, during IPA-CP propagation
phase, I use an (edge) summary that is basically only a pointer to
cgraph_edge. I'd even prefer that the default duplication hook would
just do an assignment or a memcpy.
>
> > 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
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).
Thanks,
Martin