This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, PATCH]: Introduction of callgraph annotation class
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Martin LiÅka <mliska at suse dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Thu, 16 Oct 2014 13:31:13 +0200
- Subject: Re: [RFC, PATCH]: Introduction of callgraph annotation class
- Authentication-results: sourceware.org; auth=none
- References: <543EA03A dot 7000000 at suse dot cz>
On Wed, Oct 15, 2014 at 6:26 PM, Martin LiÅka <mliska@suse.cz> wrote:
> Hello.
>
> Following patch introduces a new class called callgraph_annotation. Idea
> behind the patch is to provide a generic interface one can use to register
> custom info related to a cgraph_node. As you know, symbol_table provides
> hooks for creation, deletion and duplication of a cgraph_node. If you have a
> pass, you need to handle all these hooks and store custom data in your data
> structure.
>
> As an example, after discussion with Martin, I chose usage in ipa-prop.h:
>
> data structure:
> vec<ipa_node_params> ipa_node_params_vector
>
> if the pass handles an event, following chunk is executed:
> if (ipa_node_params_vector.length () <= (unsigned) symtab->cgraph_max_uid)
> ipa_node_params_vector.safe_grow_cleared (symtab->cgraph_max_uid + 1);
>
> The problem is that you can have sparse UIDs of cgraph_nodes and every time
> you have to allocate a vector of size equal to cgraph_max_uid.
>
> As a replacement, I implemented first version of cgraph_annotation that
> internally uses hash_map<cgraph_unique_identifier, T>.
> Every time a node is deleted, we remove corresponding data associated to the
> node.
>
> What do you think about it?
I don't like "generic annotation" facilities at all. Would it be possible
to make cgraph UIDs not sparse? (keep a free-list of cgraph nodes
with UID < cgraph_max_uid, only really free nodes at the end)
Using a different data structure than a vector indexed by cgraph UID
should also be easily possible (a map from UID to data, hash_map <int, T>).
Richard.
> Thank you,
> Martin