> On 9/5/12, Xinliang David Li <davi...@google.com> wrote: > > On Sep 5, 2012 Jan Hubicka <hubi...@ucw.cz> wrote: > > > OK, the basic idea is that symtab_node is basetype of > > > cgraph_node and varpool_node. We may want to drop the historica > > > cgraph/varpool names here, since function_node/variable_node > > > would sound better. Cgraph still exists, but varpool is more > > > or less historical relic. > > > > The cgraph redesign probably deserves more discussion. > > Hence, the post! > > > 1) It may be worthwhile to abstract the graph manipulation code > > into a utility class which is templatized. > > > > graph<T>, node<T> with node inheriting from T. > > While I won't dispute the statement, getting from here to there > will likely involve some intermediate steps.
Commonizing some of cfg/cgraph/ssa graph handling would not hurt, but there is not _that_ much code in common - we do some strongly connected components discovery on all three kinds of graphs and basic traversals. > > > 2) Introduce a global symbol table containing a function table > > and a global variable table. The function table should replace > > the current cgraph node link list, and the variable table replaces > > the varpool. The symbol table should provide basic interfaces to > > do named based lookup, traversal, alias handling etc. I noticed > > trunk already has some of that -- but it seems more abstraction > > is needed. > > Do you mean moving away from a pointer-based approach? I would say that trunk now have what is described here. I still plan to unify some of code (like alias handling) that is split for historical reasons, but those are mostly cleanups still intended for 4.8. Honza
