This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cgraph Modification Plan


On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> 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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]