[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