This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> > > +            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 ;)

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]