This is the mail archive of the
mailing list for the GCC project.
Re: [RFC, PATCH]: Introduction of callgraph annotation class
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Martin Liška <mliska at suse dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 16 Oct 2014 14:01:50 +0200
- Subject: Re: [RFC, PATCH]: Introduction of callgraph annotation class
- Authentication-results: sourceware.org; auth=none
- References: <543EA03A dot 7000000 at suse dot cz> <CAFiYyc12P-DMR=7otSYN+G6DJLK=y+EN7c4sBFZBk1=Lgz9Mzw at mail dot gmail dot com> <543FAF1A dot 8030907 at suse dot cz> <CAFiYyc1Dh8Z_7YgLH-BjPmh6UJtPOj6uZKeuQavY91T=qPfofg at mail dot gmail dot com>
> > 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
> > Martin
> >> Richard.
> >>> Thank you,
> >>> Martin