On Wed, Sep 5, 2012 at 9:32 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> 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. >>
Once we have the common infrastructure for graphs, new uses will be easily created (e.g, dynamic callgraph in profile-gen runtime analysis, module graph, etc) -- graph is one of the most basic data structures for compilers. David >> > 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
