为什么 GCC 不能为两个 int32s 的结构生成最佳 operator==？

如何解决为什么 GCC 不能为两个 int32s 的结构生成最佳 operator==？

一位同事向我展示了我认为不需要的代码，但确实如此。我希望大多数编译器会将所有这三种相等性测试的尝试视为等效的：

#include <cstdint>
#include <cstring>

struct Point {
    std::int32_t x,y;
};

[[nodiscard]]
bool naiveEqual(const Point &a,const Point &b) {
    return a.x == b.x && a.y == b.y;
}

[[nodiscard]]
bool optimizedEqual(const Point &a,const Point &b) {
    // Why can't the compiler produce the same assembly in naiveEqual as it does here?
    std::uint64_t ai,bi;
    static_assert(sizeof(Point) == sizeof(ai));
    std::memcpy(&ai,&a,sizeof(Point));
    std::memcpy(&bi,&b,sizeof(Point));
    return ai == bi;
}

[[nodiscard]]
bool optimizedEqual2(const Point &a,const Point &b) {
    return std::memcmp(&a,sizeof(a)) == 0;
}


[[nodiscard]]
bool naiveEqual1(const Point &a,const Point &b) {
    // Let's try avoiding any jumps by using bitwise and:
    return (a.x == b.x) & (a.y == b.y);
}

但令我惊讶的是，只有带有 memcpy 或 memcmp 的那些才会被 GCC 转换为单个 64 位比较。为什么？ (https://godbolt.org/z/aP1ocs)

对于优化器来说，如果我在连续的四个字节对上检查相等性，这与比较所有八个字节是否相同，这不是很明显吗？

尝试避免将两部分单独布尔化会更有效地编译（减少一条指令并且对 EDX 没有错误依赖），但仍然是两个单独的 32 位操作。

bool bithackEqual(const Point &a,const Point &b) {
    // a^b == 0 only if they're equal
    return ((a.x ^ b.x) | (a.y ^ b.y)) == 0;
}

---

GCC 和 Clang 在通过 value 传递结构时都具有相同的未优化优化（因此 a 在 RDI 中，b 在 RSI 中，因为 x86-64 就是这样System V 的调用约定将结构打包到寄存器中）：https://godbolt.org/z/v88a6s。 memcpy / memcmp 版本都编译为 cmp rdi,rsi / sete al，但其他版本执行单独的 32 位操作。

struct alignas(uint64_t) Point 令人惊讶的是，在参数在寄存器中的按值情况下仍然有帮助，优化了 GCC 的两个 naiveEqual 版本，但不是 bithack XOR/OR。 (https://godbolt.org/z/ofGa1f)。这是否给我们提供了有关 GCC 内部结构的任何提示？对齐对 Clang 没有帮助。

解决方法

如果你“修复”了对齐方式，都会给出相同的汇编语言输出（使用 GCC）：

struct alignas(std::int64_t) Point {
    std::int32_t x,y;
};

Demo

请注意，一些正确/合法的方法（如类型双关语）是使用 memcpy，因此在使用该函数时进行特定优化（或更具侵略性）似乎合乎逻辑。

,

将其作为单个 64 位比较实现时，您可能会遇到性能悬崖：

你打破商店加载转发。

如果结构体中的 32 位数字通过单独的存储指令写入内存，然后使用 64 位加载指令快速从内存加载回（在存储达到 L1$ 之前），您的执行将停止直到存储提交到全局可见的缓存一致性 L1$。如果加载是与之前的 32 位存储匹配的 32 位加载，现代 CPU 将通过在存储到达缓存之前将存储值转发到加载指令来避免存储加载停顿。如果多个 CPU 访问内存（一个 CPU 以与其他 CPU 不同的顺序查看自己的存储），这会违反顺序一致性，但大多数现代 CPU 架构，甚至 x86 都允许这样做。转发还允许完全推测性地执行更多代码，因为如果必须回滚执行，则没有其他 CPU 可以看到使用此 CPU 上加载值的代码的存储以推测性执行。

如果您希望它使用 64 位操作并且您不希望出现这种性能悬崖，您可能希望确保该结构也始终编写为单个 64 位数字。

,

为什么编译器不能生成[与memcpy版本相同的程序集]？

在允许的意义上，编译器“可以”。

编译器根本就没有。为什么它不超出我的知识范围，因为这需要深入了解优化器是如何实现的。但是，答案可能从“没有涵盖这种转换的逻辑”到“规则没有调整为假设一个输出比另一个更快”在所有目标 CPU 上。

如果您使用 Clang 而不是 GCC，您会注意到它为 naiveEqual 和 naiveEqual1 产生相同的输出，并且该程序集没有跳转。除了使用两条 32 位指令代替一条 64 位指令外，它与“优化”版本相同。此外，如 Jarod42 的 answer 所示，限制 Point 的对齐对优化器没有影响。

MSVC 的行为类似于 Clang，因为它不受对齐的影响，但不同的是它没有摆脱 naiveEqual 中的跳转。

就其价值而言，编译器（我检查了 GCC 和 Clang）为 C++20 默认比较生成的输出与它们为 naiveEqual 所做的输出基本相同。无论出于何种原因，GCC 选择使用 jne 而不是 je 进行跳转。

这是缺少编译器优化吗

假设在目标 CPU 上一个总是比另一个快，那将是一个公平的结论。