Cgraph Modification Plan

[Lawrence Crowl]

On 9/5/12, Xinliang David Li <davidxl@google.com> wrote:
> On Sep 5, 2012 Jan Hubicka <hubicka@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