rtti data structures (again)

[Jason Merrill]

>>>>> Nathan Sidwell <sidwell at codesourcery.com> writes:

 > I fail to see how the catch matcher can get different results comparing
 > __tiPP1B to __tiPCPC1A as opposed to comparing __tiPP1B to __tiPCPC1B.
 > They both look like qualification conversions of pointers to pointers to
 > incomplete type.

Good point.  I was forgetting about multi-level qualification conversions.

I think that leaves us with something like what EDG does now: namely,
comparisons are done by comparing the addresses of one-byte commons rather
than of the type_info nodes themselves.  Then we could emit incomplete info
in one file and complete info in another file and they would compare the
same because both refer to the same ID proxy.

We could mangle the complete and incomplete versions differently, so they
would not be combined by the linker.

This would also change how we refer to type_infos; under the current
scheme, references to type_infos in the EH type table need to be via relocs
that will be resolved by the dynamic linker at runtime.  If we don't need
to compare addresses, we could use gp-relative references.  Of course, we'd
still have the absolute references in the type_infos to the ID proxies, so
we're no better off.

 >> We also decided that the flags should move from __class_type_info into
 >> __vmi_class_type_info, and that the polymorphic flag should be removed.

 > I think this moving of the flags is a mistake. If I understood correctly,
 > they indicated information about direct and indirect bases (whether there
 > was virtuality anywhere in the heirarchy for instance). Such information
 > can speed up dynamic cast. When walking the inheritance graph, we can
 > take some early outs, if we know there are no multiple sub object types
 > within the complete graph. With the flags in every class's type_info, it
 > becomes easier to get hold of that info. With it only for vmi classes,
 > we have to remember `unknown' when presented with a complete object of
 > si type, and fill the information in when/if we find a vmi base.

So what you're saying is if we try to dynamic_cast from A* to B*, where B
has a unique A subobject and the A* does not actually point to part of a B,
if we know that B has no multiple subobjects we can check the passed
offset, see that it doesn't match, and return failure.  Without that
information, we would have to recurse up the single-inheritance chain until
we either reach the A or a class with multiple or virtual bases.

I think I'd rather pay that small performance hit than add a word to the
type_info for each class.  Matt, would this affect locales?

 > Another case is in a potential cross-cast case, which I had in the
 > previous email.  Suppose we've found the target base, which we know is
 > unique, but not found the source base (because we early outed,
 > maybe). To be a valid cross-cast both the source and target base objects
 > must be public in the complete object. If we know the complete heirarchy
 > has no non-public bases, there's no need to search for the source base
 > in this case.

But cross-casts only come up in the context of classes with multiple bases,
so it wouldn't make sense to look for this in single inheritance classes
anyway.

Jason