Using known data structure hierarchy in GC and PCH?

Steven Bosscher stevenb.gcc@gmail.com
Tue Dec 11 19:50:00 GMT 2012


On Tue, Dec 11, 2012 at 6:55 PM, Martin Jambor wrote:
> some IPA passes do have on-the side vectors with their information
> about each cgraph node or edge and those are independent GC roots.
> Not all, but many (e.g. inline_summary_vec or ipa_edge_args_vector) do
> have pointers to other GC data, usually trees, and thus are mananged
> by GC too.  Many of those trees (e.g. constants) might not be
> reachable at least in LTO WPA phase.  Sure enough, inventing something
> more clever for them might be a good idea.

I wasn't really thinking of 'tree' anyway; 'tree' is way too complex for this.

I'm more thinking of pointers from on-the-side data to cgraph
nodes/edges, and of pointers within the cgraph objects that are
"redundant" from a GC marking point of view. Those pointers should
only point to reachable cgraph nodes/edges, so it shouldn't be
necessary to mark them separately when walking the on-the-side data.

Take, for instance, "struct cgraph_edge" where all pointer fields are
reachable via other pointers already:

struct cgraph_edge {
...
  struct cgraph_node *caller; // reachable via symtab_nodes
  struct cgraph_node *callee; // reachable via symtab_nodes
  struct cgraph_edge *prev_caller; // reachable via symtab_nodes
  struct cgraph_edge *next_caller; // reachable via symtab_nodes
  struct cgraph_edge *prev_callee; // reachable via symtab_nodes
  struct cgraph_edge *next_callee; // reachable via symtab_nodes
  gimple call_stmt; // reachable via the CFG that contains the call
...
}

so, at least in theory, it shouldn't be necessary to do anything for a
cgraph_edge.
Unless I'm missing something...

Ciao!
Steven


PS: shouldn't "struct symtab_node" have GTY next/prev markers?



More information about the Gcc mailing list