> On Mon, Jun 9, 2014 at 4:34 AM, Jan Hubicka <hubi...@ucw.cz> wrote: > > Hi, > > this patch follows the change to move DECL_COMDAT_GROUP by moving > > DECL_SECTION_NAME > > into symtab nodes instead of keeping it in decl_with_vis. (I pla to proceed > > with > > other symbol table related fields). > > > > It follows exactly same path as the previous patch. Notable change is adding > > of node removal into duplicate_decl in c-decl.c. > > > > Memory usage wise the patch is small win for non-WPA, at WPA we actually > > consume bit more memory (about 800K on Firefox). We have more symtab nodes > > than declarations because of inline clonning. This will be solved by fixing > > memory representation of symbol nodes (I plan to move rare items into on > > side > > hashtables). With accessors API it should be easy. > > What I wondered about for some time is why 'clones' need to use the > same structs as their origins. They share some bits with their origin > and they apply some changes. Thus I think it would be nice to change > the inheritance of a symtab entry to sth like > > symbol - cgraph-node-base - cgraph-node > | \ > | cgraph-clone > varpool-node-base - varpool-node > \ > varpool-clone (do we have those?)
Yep, revisiting hiearchy of symbol is on my TODO list. I want to clear APIs first to make it easier. We can also make difference in between external declarations, definitions, thunks and aliases so we do not share data for all of them. One problem is that we change one type of symbol into another. We would need tool for that - allocating duplicate node and redirecting datastructures. Not a big deal, but not that pretty either (I think we do not really dangle pointers to nodes, but I am not 100% sure) Still those rare data (i.e. things that are not set for most of nodes) probably should sit in on side hashtable. Honza
