Re: [RFC, PATCH]: Introduction of callgraph annotation class

[Jan Hubicka <hubicka at ucw dot cz>]

> > Hello.
> >
> > If I recall correctly, we recycle cgraph_nodes and it's possible that an UID
> > is given to different nodes:
> > symbol_table::allocate_cgraph_symbol (void). Such uid is problematic from
> > perspective that it cannot be used as a index to a vector.
> >
> > It was also Honza's note that one can choose inner implementation of such
> > annotation class. We can implement both sparse (hash_map) and consecutive
> > vector data structure.
> >
> > According to first numbers I was given, Inkscape allocates about ~64k
> > cgraph_nodes in WPA. After function merging is processed, it shrinks to
> > about a half. So that, our free list contains the half of nodes. If we use
> > consecutive vector, our memory impact is bigger thank necessary.
> 
> I don't think there is anything that forces us to retain the original
> UID allocation after WPA merging?  So why not compact it?

We could, if we have way to update the summaries that are currently UID allocated.
With annotation template we could have handle to do that more easily than diving into
each of passes maintaining summaries by hand.

On the other hand it still does not make the records quite dense in cases
 1) you do not want to have separate records for clones because you know clones
    and master are identical
 2) you care only about definitions 
...
At some point we discussed introducing separate UIDs for those but that was also
not very welcome (and I agree we already have bit too many UIDs for functions - DECL_UID,
node->uid, DECL_STRUCT_FUNCTION (node)->uid, profile_uid

I tried to get rid of DECL_STRUCT_FUNCTION uid at some point, but did not quite finished
it.

Honza
> 
> Richard.
> 
> > Martin
> >
> >
> >>
> >> Richard.
> >>
> >>> Thank you,
> >>> Martin
> >
> >