[libcxx-dev] Is the implementation of two-argument __non_unique_arm_rtti_bit_impl; ; __is_type_name_unique correct?
Stephan Bergmann via libcxx-dev
libcxx-dev at lists.llvm.org
Wed Dec 16 06:07:21 PST 2020
About the code originally introduced into libcxx/include/typeinfo as
> _LIBCPP_INLINE_VISIBILITY
> bool operator==(const type_info& __arg) const _NOEXCEPT
> #ifndef _LIBCPP_NONUNIQUE_RTTI_BIT
> {return __type_name == __arg.__type_name;}
> #else
> {if (__type_name == __arg.__type_name) return true;
> if (!((__type_name & __arg.__type_name) & _LIBCPP_NONUNIQUE_RTTI_BIT))
> return false;
> return __compare_nonunique_names(__arg) == 0;}
> #endif
in
<https://github.com/llvm/llvm-project/commit/0090e657cb3a477ace4db59a6b5ae80baffec4c5>
"ARM64: compare RTTI names as strings", and then factored out to
> _LIBCPP_INLINE_VISIBILITY
> static bool __is_type_name_unique(__type_name_t __lhs, __type_name_t __rhs) _NOEXCEPT {
> return !((__lhs & __rhs) & __non_unique_rtti_bit::value);
> }
in
<https://github.com/llvm/llvm-project/commit/2405bd6898151e0a7ffede78b0d0c7c85c0b66d3>
"Rework std::type_info definition to support systems without fully
merged type info names":
I wonder if it is correct to compute `__lhs & __rhs` rather than `__lhs
| __rhs`? The documentation of NonUniqueARMRTTIBit (also in
libcxx/include/typeinfo) states that "we check whether BOTH type_infos
are guaranteed unique, and if so, we simply compare the addresses of
their type names instead of doing a deep string comparison, which is
faster. If at least one of the type_infos can't guarantee uniqueness,
we have no choice but to fall back to a deep string comparison."
So my understanding is that __is_type_name_unique should return false
(and comparison fall back to deep string comparison) when at least one
of __lhs and __rhs has the __non_unique_rtti_bit set, not only when both
have it set.
More information about the libcxx-dev
mailing list