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. > 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? > 3) it seems natural to drop 'node' in the naming scheme > > symbol (symtab_entry) --> base class; > function --> derived from symbol; (It conflicts with the existing > struct function though); > variable --> derived from symbol; > > typedef node<function> cnode; A node<function> is not a derived class of node<symbol> even when function is derived from symbol. That property is helpful in ensuring usable type safety. > 4) coding convention is needed for functions that do 'casting' > and 'trial casting'. The functions I have suggestion are ptr_... and try_... respectively. Are you suggesting amending the coding conventions? -- Lawrence Crowl
