> > 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.
Yep, I would hope there is a vairant that makes simple types easy but still allows to put non-PODs into the summaries (or is that possible with current code?) Perhaps we can have a base class that provides default implementation of the insertion/duplication ctor via the default ctor/copy ctor? That would still require to wrap your pointer in a trivial class, but you would not need to write any methods. The container is template anyway, so one would not need virtual methods for the maintainance? > > > > > > 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, I will read the actual implementation and of our C++ guys are fine with the current form, I think we can give it a try. Refining the "hooks" part of the API incrementally should be easy. Honza > > Thanks, > > Martin
