On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl <cr...@googlers.com> 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.
Yes. My point is that the intermediate steps should be driven by the final goal. It is important to first have the design of final class hierarchy and interfaces nailed and then the intermediate steps defined instead of the other way around. > >> 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? See above. I mean it is important to have well defined symtab interfaces that hide implementation as much as possible. It will make the interfaces more stable. It is currently quite difficult for cgraph/varpool related changes in gcc branches to keep up with trunk without stable core APIs. > >> 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. We don't need node<symbol> -- only node<function> is needed, and it is derived from function and function is derived from symbol. > >> 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? > Is this something agreed upon in previous discussions or something newly brought up? How about using template function in base to do casting: trial cast: template<typename T> T* symbol::cast_to(symbol* p) { if (p->is<T>()) return static_cast<T*>(p); return 0; } cast: template<typename T> T& symbol:as(symbol* p) { assert(p->is<T>()) return static_cast<T&>(*p); } David > -- > Lawrence Crowl