clang实现char8_t的方式是否存在缺陷，或者标准的某个黑暗角落是否禁止优化?

Is there a flaw in how clang implements char8_t or does some dark corner of the standard prohibit optimization?

本文关键字：是否 标准 黑暗角落 优化 禁止 或者 缺陷 char8 实现 方式 clang      更新时间：2023-10-16

clang 8.0.0 引入了对 C++20char8_t类型的支持。但是，我希望以下函数具有相同的编译器输出

#include <algorithm>
bool compare4(char const* pcha, char const* pchB, int n) {
return std::equal(pcha, pcha+4, pchB);
}
bool compare4(char8_t const* pchA, char8_t const* pchB, int n) {
return std::equal(pchA, pchA+4, pchB);
}

但是，它们在-std=c++2a -O2下编译

compare4(char const*, char const*, int):   # @compare4(char const*, char const*, int)
mov     eax, dword ptr [rdi]
cmp     eax, dword ptr [rsi]
sete    al
ret
_Z8compare4PKDuS0_i:                       # @_Z8compare4PKDuS0_i
mov     al, byte ptr [rdi]
cmp     al, byte ptr [rsi]
jne     .LBB1_4
mov     al, byte ptr [rdi + 1]
cmp     al, byte ptr [rsi + 1]
jne     .LBB1_4
mov     al, byte ptr [rdi + 2]
cmp     al, byte ptr [rsi + 2]
jne     .LBB1_4
mov     al, byte ptr [rdi + 3]
cmp     al, byte ptr [rsi + 3]
sete    al
ret
.LBB1_4:
xor     eax, eax
ret

其中后者显然不太优化。 这有什么原因(我在标准中找不到任何原因)还是这是 clang 中的错误？

  1. 在libstdc++中，当std::equal检测到参数是"简单"时，它会调用__builtin_memcmp，否则它会使用朴素的for循环。这里的"简单"是指指向同一整数或指针类型的指针(或指针周围的某些迭代器包装器)。(相关源代码)

    • 一个类型是否是整数类型是由内部__is_integer特征检测的，但是libstdc++ 8.2.0(godbolt.org 上使用的版本)并没有将此特征专门用于char8_t，因此后者不会被检测为整数类型。相关源代码)

  2. Clang (使用此特定配置)在 for 循环情况下生成的程序集比在__builtin_memcmp情况下生成更详细的程序集。

    3. (但前者在性能方面的优化不一定较少。请参阅Loop_unrolling。

所以这种差异是有原因的，这不是 clang IMO 中的错误。

这不是 Clang 中的"错误";只是错失了优化的机会。

您可以使用采用基础类型为unsigned char的enum class的相同函数来复制 Clang 编译器输出。相比之下，GCC 识别具有基础类型的unsigned char和char8_t的枚举器之间的差异。它为unsigned char和char8_t发出相同的代码，但对于enum class情况发出更复杂的代码。

因此，关于 Clang 的char8_t实现，似乎更多地将其视为用户定义的枚举，而不是基本类型。最好将其视为标准的早期实施。

应该注意的是，unsigned char和char8_t之间最重要的区别之一是混叠要求。unsigned char指针可能与几乎所有其他内容混叠。相比之下，char8_t指针不能。因此，可以合理地期望(在成熟的实现上，而不是超过它实现到市场的标准)在不同情况下发出不同的代码。诀窍是，如果char8_t代码不同，它应该更有效率，因为编译器不再需要发出执行额外工作的代码来处理来自存储的潜在别名。

相关文章：