[PATCH v2 1/6] Convert symtab, cgraph and varpool nodes into a real class hierarchy

Richard Biener richard.guenther@gmail.com
Wed Sep 18 10:37:00 GMT 2013


On Wed, Sep 18, 2013 at 9:24 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > > +            cgraph_node *cgn = static_cast <cgraph_node *> (x);
>> > > +            gt_ggc_m_11cgraph_edge (cgn->callers);
>> > > +            gt_ggc_m_11cgraph_node (cgn->origin);
>> > > +            gt_ggc_m_11cgraph_node (cgn->nested);
>> > > +            gt_ggc_m_11cgraph_node (cgn->next_nested);
>> > > +            gt_ggc_m_11cgraph_node (cgn->next_sibling_clone);
>> > > +            gt_ggc_m_11cgraph_node (cgn->prev_sibling_clone);
>> > > +            gt_ggc_m_11cgraph_node (cgn->clones);
>> > > +            gt_ggc_m_11cgraph_node (cgn->clone_of);
>> > Same as here.
>>
>> Sorry, it's not clear to me what you meant by "Same as here." here.  Do
>> you mean that I can skip marking them because they're within the symbol
>> table?   If so, are you referring to all 10 fields above ("callees"
>> through "clone_of")?
>
> All those pointers above points inside symbol table, so none of them needs
> to be marked.  Actually those two needs however, I missed them with prevoius
> reading:
>> > > +            gt_ggc_m_11cgraph_edge (cgn->indirect_calls);
>> > > +            gt_ggc_m_11cgraph_edge (cgn->callees);
>
> Otherwise edges will probably get lost.
>>
>>
>> >
>> > > +            gt_ggc_m_P11cgraph_edge4htab (cgn->call_site_hash);
>> > Move call site hash out of GGC rather than introducing hack.
>>
>> I see that this is allocated in cgraph_edge (), and it appears to be an
>> index.  I can create it with htab_create rather than htab_create_ggc,
>> but if so, there doesn't seem a natural place to call htab_delete.  Is
>> that OK?
>
> Delete it in cgraph_remove_node.
>>
>>
>> > > +            gt_ggc_m_9tree_node (cgn->former_clone_of);
>> > > +            gt_ggc_m_11cgraph_node (cgn->global.inlined_to);
>> > And here
>>
>> Again, do you mean that "inlined_to" can be skipped since it's in the
>> symbol table?
>
> yes.
>> > > +            cgraph_node *cgn = static_cast <cgraph_node *> (x);
>> > > +            gt_pch_n_11cgraph_edge (cgn->callees);
>> > > +            gt_pch_n_11cgraph_edge (cgn->callers);
>> > > +            gt_pch_n_11cgraph_edge (cgn->indirect_calls);
>> > > +            gt_pch_n_11cgraph_node (cgn->origin);
>> > > +            gt_pch_n_11cgraph_node (cgn->nested);
>> > > +            gt_pch_n_11cgraph_node (cgn->next_nested);
>> > > +            gt_pch_n_11cgraph_node (cgn->next_sibling_clone);
>> > > +            gt_pch_n_11cgraph_node (cgn->prev_sibling_clone);
>> > > +            gt_pch_n_11cgraph_node (cgn->clones);
>> > > +            gt_pch_n_11cgraph_node (cgn->clone_of);
>> > > +            gt_pch_n_P11cgraph_edge4htab (cgn->call_site_hash);
>> > > +            gt_pch_n_9tree_node (cgn->former_clone_of);
>> > > +            gt_pch_n_11cgraph_node (cgn->global.inlined_to);
>> > > +            gt_pch_n_28vec_ipa_replace_map_p_va_gc_ (cgn->clone.tree_map);
>> > > +            gt_pch_n_15bitmap_head_def (cgn->clone.args_to_skip);
>> > > +            gt_pch_n_15bitmap_head_def (cgn->clone.combined_args_to_skip);
>> > > +            gt_pch_n_9tree_node (cgn->thunk.alias);
>> >
>> > We can skip good part of those. Just small of those is build at PCH time. But lets do that incrementally, PCH is touchy business.
>>
>> OK.  I'll just make analogous changes here to those made to the
>> gt_ggc_mx function.
>
> I think some of the pointers that do not need to be marked still needs to be
> streamed and fixed by PCH, so we probably want to keep them.  All the cloning
> pointers above are not live at PCH time (they are always NULL).  Only reason
> why PCH lives at that point is that C++ FE produces Cgraph nodes early for
> funny reason. The nodes are not analyzed at that point and call edges do not
> exist (if I recall right) Probably I can do this incrementally - we do not want
> to break PCH with a large patch and then spend weeks analyzing it.  That things
> can bite ;)

Debugging omissions / errors in manually written markers will indeed be a
PITA :/

Richard.

> Honza



More information about the Gcc-patches mailing list