[PATCH] D154658: Optimize emission of `dynamic_cast` to final classes.

Fri Jul 7 10:08:41 PDT 2023

rjmccall added a comment.

In D154658#4479213 <https://reviews.llvm.org/D154658#4479213>, @rsmith wrote:

> In D154658#4479170 <https://reviews.llvm.org/D154658#4479170>, @rjmccall wrote:
>
>> I don't think it's an intended guarantee of the Itanium ABI that the v-table will be unique, and v-tables are frequently not unique in the presence of shared libraries.
>
> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-general explicitly guarantees this: "[...] However, the virtual table pointers within all the objects (instances) of a particular most-derived class point to the same set of virtual tables."

Huh, I've never noticed that before.  I still don't think it's satisfied in practice, at least in the presence of shared libraries.  This is notably the exact same setup that eventually forced (or "forced") GCC to start using string comparison for RTTI instead of the ABI-prescribed algorithm that relies on `_ZTS` pointer equality.

>> They should be unique for classes with internal linkage, but of course that's a vastly reduced domain for the optimization.
>
> I think (hope?) we should be able to apply this to a much larger set of cases. Would it be correct to do this optimization unless the vtable might be emitted with vague linkage and non-default visibility (that is, unless we're in the odd case where people expect non-default visibility classes to be the same type across DSOs)? Or are there cases where we might be using a vtable that (eg) doesn't even have the right symbol?

I don't know of any problems other than the total failure of vague linkage across DSO boundaries, so if we just treat that as an implicit exception to the vtable uniqueness guarantee in the ABI, I think you've got the condition exactly right: we could do this for any class where either the v-table doesn't have vague linkage or the class's formal visibility is not `default`.  Our experience at Apple with enforcing type visibility is that it's usually good for one or two bug reports a year, but it's pretty easy to explain to users what they did wrong, and Clang's visibility attributes are pretty simple to use.  (`type_visibility` helps a lot with managing tradeoffs.)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154658/new/

https://reviews.llvm.org/D154658