[libcxx-dev] Is the implementation of two-argument __non_unique_arm_rtti_bit_impl; ; __is_type_name_unique correct?

[Louis Dionne via libcxx-dev]

> On Dec 16, 2020, at 09:07, Stephan Bergmann via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> 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.

Hi,

Yes, I do follow your thinking and I think you’re right. I went ahead and created a review (https://reviews.llvm.org/D97802 <https://reviews.llvm.org/D97802>) to avoid forgetting about this. I’ll need to investigate some more to make sure your interpretation is correct.

Thanks,
Louis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20210302/90e1e385/attachment.html>