[RFC, PATCH]: Introduction of callgraph annotation class

[Martin Liška]

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
>>>
>>>