This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC, PATCH]: Introduction of callgraph annotation class


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]