This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 09/14] Remove cgraph_node::summary_uid and make cgraph_node::uid really unique.
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: marxin <mliska at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 7 Jun 2018 14:09:48 +0200
- Subject: Re: [PATCH 09/14] Remove cgraph_node::summary_uid and make cgraph_node::uid really unique.
- References: <cover.1526551813.git.mliska@suse.cz> <9ea573c8288da886c1eaf19946ee1ac373026fe5.1526551813.git.mliska@suse.cz>
>
> gcc/ChangeLog:
>
> 2018-05-16 Martin Liska <mliska@suse.cz>
>
> * cgraph.c (cgraph_node::remove): Do not recycle uid.
> * cgraph.h (symbol_table::release_symbol): Do not pass uid.
> (symbol_table::allocate_cgraph_symbol): Do not set uid.
> * passes.c (uid_hash_t): Record removed_nodes by their uids.
> (remove_cgraph_node_from_order): Use the removed_nodes set.
> (do_per_function_toporder): Likwise.
> * symbol-summary.h (symtab_insertion): Use cgraph_node::uid
> instead of summary_uid.
> (symtab_removal): Likewise.
> (symtab_duplication): Likewise.
>
> gcc/lto/ChangeLog:
>
> 2018-05-16 Martin Liska <mliska@suse.cz>
>
> * lto-partition.c (lto_balanced_map): Use cgraph_node::uid
> instead of summary_uid.
I am still now convinced that competely moving from arrays made dense by
uid recyclic to hash tables is performance-wise smart idea, but current
uid is not working very well for this purpose - most summaries we have
are only for definitions so we want something like definition uid.
In general it seems bad that we allocate same memory for object with definition
and external symbol. Something I planned to change but did not get to do that yet.
So the patch is OK. With new abstraction we can always re-invent dense uids for
this purpose later.
Honza