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 9/12/12, Jan Hubicka <hubicka@ucw.cz> wrote:
>> We do not yet seem to have consensus on a long term plan.
>> Would it be reasonable to start on short term prepatory work?
>>
>> In particular, I was think we could do
>>
>>    Add converters and testers.
>>    Change callers to use those.
>>
>> and maybe
>>
>>    Change callers to use type-safe parameters.
>>
>> Where those mean what I earlier stated.
>>
>> Comments?
>
> Yes, it seems sane.
>
>>
>> CONVERTERS AND TESTERS ###########################################
>>
>> add
>>     symtab_node_base &symtab_node_def::ref_symbol()
>> 	{ return symbol; }
>>     symtab_node_base &cgraph_node::ref_symbol()
>> 	{ return symbol; }
>>     symtab_node_base &varpool_node::ref_symbol()
>> 	{ return symbol; }
>>
>> change
>>     node->symbol.whatever
>> to
>>     node->ref_symbol().whatever
>
> I still do not gather why simple inheritance can't let me to write
> node->whatever again...
>
> If that is GTY limitation, I have no problem having this in
> short term and update it later.  symbol_node is really base of
> functions/variables and new beasts we are going to get soon.
> I implemented it as union only to make GTY happy.

It is a GTY limitation right now.  We can do most of this work before
gengtype supports inheritance, and for that we need ref_symbol.

>>
>> ----
>>
>> should not need to add these
>>
>>     cgraph_node &symtab_node_def::ref_cgraph()
>> 	{ gcc_assert (symbol.type == SYMTAB_FUNCTION);
>
> I think checking_assert is enough in these cases. We are getting
> more conversions back and forth and we don't really want to have
> asserts all around code.

The are untested conversions from base to derived.  We should not
be using them, and hence they should be rare.  I mention them only
because there might be places in the code where we get backed into
a corner.  I've changed my notes to use gcc_checking_assert, and
we can revisit the decision whenever we need to.

>> 	  return x_function; }
>>     varpool_node &symtab_node_def::ref_varpool()
>> 	{ gcc_assert (symbol.type == SYMTAB_VARIABLE);
>> 	  return x_variable; }
>>
>> ----
>>
>> add
>>     symtab_node_base *symtab_node_def::try_symbol()
>> 	{ return &symbol; }
>>     cgraph_node *symtab_node_def::try_cgraph()
>> 	{ return symbol.type == SYMTAB_FUNCTION ? &x_function : NULL; }
>>     varpool_node *symtab_node_def::try_varpool()
>> 	{ return symbol.type == SYMTAB_VARIABLE ? &x_variable : NULL; }
>
> I think try_function/try_variable reads better than cgraph/varpool
> especially with the longer term plan to drop these names when
> cgraph/varpool no longer exists and we have symbol table.

Okay, I will do that.

-- 
Lawrence Crowl


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