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