https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #24 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Thomas de Bock from comment #21) > (In reply to Jakub Jelinek from comment #20) > > (In reply to Thomas de Bock from comment #18) > > > (In reply to Jason Merrill from comment #17) > > > > As I commented at > > > > > > > > https://inbox.sourceware.org/gcc-patches/75ff8af8-af03-42fa-b68b- > > > > [email protected]/ > > > > > > > > we could optimize the dynamic_cast to type_info::operator== instead of > > > > vtable comparison. > > > > > > I agree having dynamic_cast be optimized to type_info::operator== when it > > > can (and when optimizations are enabled) would be good. Like I said > > > though I > > > also think having an optimal optimization that just checks vtables ptrs is > > > important to have available behind some compiler flags as well. > > > > With <typeinfo> being included, that option would already exist, > > -D__GXX_MERGED_TYPEINFO_NAMES=1 > > How so? The definition is: > type_info::operator==(const type_info& __arg) const _GLIBCXX_NOEXCEPT > { > if (std::__is_constant_evaluated()) > return this == &__arg; > > if (__name == __arg.__name) > return true; > ... > > so even with __GXX_MERGED_TYPEINFO_NAMES=1, the type_info name ptrs will be > compared, requiring additional dereferences compared to just a vtable ptr > comparison, no? Sure, but that tiny optimization doesn't seem worth adding a compiler flag and trying to teach users about it. But the LLVM discussion (https://reviews.llvm.org/D154658) suggests cases where this optimization can be done safely: namely, when the final class has no base of the input type (so we can warn and just throw or return null) or the vtable has external non-vague linkage (so there's only one copy anyway).
