Re: Traversing typedef hierarchy in C/C++ tree

[Boris Kolpackov <boris at codesynthesis dot com>]

Hi Ian,

Ian Lance Taylor <iant@google.com> writes:

> Boris Kolpackov <boris@codesynthesis.com> writes:
>
> > Yes, that's what I suspect. Which is unfortunate since GCC already creates
> > all the nodes. All that is left is to establish a link between two types.
> > While this is not necessary for C/C++ compilation, it could be useful for
> > other tools that can now be built with the GCC plugin architecture.
>
> If you can make that work without using any extra memory and without
> making it more expensive to handle typedefs, I expect that the patch
> would be acceptable.

I took a look at it and did some pondering. It doesn't seem it will be
easy to meet both of the above requirements. We have to keep the
main_variant member in struct tree_type because getting to the main
variant is a very frequent operation. I don't think replacing it
with a loop that goes up the tree from a leaf node to the root is
an option.

We also have to keep the linked list of all the variants (the
next_variant member) because there are a couple of places in the
code that need to visit every variant.

I also looked into reusing some of the existing members that
are the same for all variants. In this case we could store the
real value in the main variant and use the member in all other
variants to organize the tree. binfo was a good candidate but then
I discovered that there is a competition for member reuse ;-) and
binfo is already taken.

I was also thinking if adding an extra member would be a big deal,
memory usage-wise. This member is only going to be added to the
TYPE nodes (struct tree_type). I may be wrong, but I would expect
that there aren't that many such nodes in a typical translation
unit. Much fewer than, say, nodes that are used to build function
bodies. Let's say we have 10,000 such nodes. Then on a 64-bit
box we will use extra ~80Kb.

What do you think?

Thanks,
	Boris