On Tue, Dec 11, 2012 at 8:49 PM, Steven Bosscher <stevenb....@gmail.com> wrote:
> 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...

No, you are correct.  All cgraph nodes are reachable from the global
symtab_node list head.  Thus _no_ pointer to a symtab_node (or its
derived kinds) require GTY tracking.  If that breaks it's a bug ;)

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

Yes.

Richard.

Reply via email to