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?
