This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Cgraph Modification Plan
On Wed, Sep 5, 2012 at 9:38 PM, Jan Hubicka <hubicka@ucw.cz> 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.
>>
>> 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.
>
> Also note that symbol table realy is an oriented multigraph with different
> types of edges (i.e. calls and references and eventualy we will have indirect
> calls with mutiple possible destinations derrived from PTA and devirtualization
> logic).
yes, but additional edge properties can also be abstracted away by
using template parameters.
David
>
> Honza