Re: Use conditional casting with symtab_node

[Lawrence Crowl <crowl at googlers dot com>]

On 10/5/12, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Thu, Oct 4, 2012 at 8:16 PM, Diego Novillo <dnovillo@google.com> wrote:
>> > On Thu, Oct 4, 2012 at 2:14 PM, Lawrence Crowl <crowl@googlers.com> wrote:
>> >
>> >> So, Jan Hubicka requested and approved the current spelling.
>> >> What now?
>> >
>> > I don't think we should hold this up.  The names Jan requested seem
>> > reasonable enough.  We seem to be running in circles here.
>>
>> I suppose I have your promise that we'll release with consistent names.
>> Please allocate some work hours on your side for the renaming of
>> cgraph_node and varpool_node for the case Honza doesn't get to it in
>> time.
>
> Not that I would not agree with Richard with most of his points.  To be
> however
> fair here, I only asked to continue naming I already introduced in:
>
> /* Return true when NODE is function.  */
> static inline bool
> symtab_function_p (symtab_node node)
> {
>   return node->symbol.type == SYMTAB_FUNCTION;
> }
>
> /* Return true when NODE is variable.  */
> static inline bool
> symtab_variable_p (symtab_node node)
> {
>   return node->symbol.type == SYMTAB_VARIABLE;
> }
>
> Even if variable are represented by varpool and functions by cgraph, I do
> not
> see these names more confusing compared to
> symtab_cgraph_p/symtab_varpool_p.
> The most common use is when you walk the symbol table and you want to
> handle
> functions and variables specially.
>
> The new interface with try_ scheme gives a bit more inconsistent feeling,
> but it is just an surface, nothing really changes.
>
> I am not happy with current naming scheme and also with the fact that for
> gengtype reasons we also have symtab_node typedef, but for varpool and
> cgraph
> we use struct (this is because symtab_node has to be union without GTY
> supporting inheritance).
>
> Introducing symtab I did not have much other options and I expected that
> at the end of this stage1 I will clean it up.  This is, well, more or less
> now
> when assuming that there are no major patches to this area just to appear
> for this stage1.
>
> I guess we all agreed we want to drop cgraph/varpool nodes in favor of
> functions/ variables.  How realistic is for gengtype to support inheritance
> this release cycle?  I would really like to see these three turned into
> classes
> with the inheritance this release cycle.  Renaming them during the process
> should be easy and just a nice bonus.

I would like some clarity.  Can I commit this patch?

-- 
Lawrence Crowl