On 10/16/2014 02:01 PM, Jan Hubicka wrote:
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.
Agree with that, I will be central point one can implement these optimizations.
One idea is to implement lazy allocation where we can allocate memory just in
case
someone calls annotation::get method.
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
It would be quite easy to implement
annotation::get_for_origin (int clone_id), where we find origin for the clone
and
return data associated to such origin node.
2) you care only about definitions
Maybe similar stuff?
Martin
...
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
