[RFC, PATCH]: Introduction of callgraph annotation class

[Martin Liška]

On 10/16/2014 02:05 PM, Martin Liška wrote:
> 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.

s/I/it

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