为什么x86-64 C / C ++编译器不能为此代码生成更有效的汇编？

问题描述

考虑以下局部变量声明：

bool a{false};
bool b{false};
bool c{false};
bool d{false};
bool e{false};
bool f{false};
bool g{false};
bool h{false};

在x86-64体系结构中，我希望优化器将这些变量的初始化减少到mov qword ptr [rsp],0之类。但是我可以尝试使用 all 编译器（无论优化级别如何）获得某种形式的

mov     byte ptr [rsp + 7],0
mov     byte ptr [rsp + 6],0
mov     byte ptr [rsp + 5],0
mov     byte ptr [rsp + 4],0
mov     byte ptr [rsp + 3],0
mov     byte ptr [rsp + 2],0
mov     byte ptr [rsp + 1],0
mov     byte ptr [rsp],0

这似乎浪费CPU周期。使用复制初始化，值初始化或用括号替换大括号没有什么区别。

但是，等等，还不止这些。假设我改为：

struct
{
    bool a{false};
    bool b{false};
    bool c{false};
    bool d{false};
    bool e{false};
    bool f{false};
    bool g{false};
    bool h{false};
} bools;

然后bools的初始化将产生我所期望的：mov qword ptr [rsp],0。有什么作用？

您可以在this Compiler Explorer link中尝试自己上方的代码。

不同编译器的行为是如此一致，以至于我不得不认为上述效率低下是有一定原因的，但我一直无法找到它。你知道为什么吗？

解决方法

编译器很笨，这是一个错过的优化。 mov qword ptr [rsp],0是最佳选择。在现代CPU上，从qword存储库到任何单个字节的字节重载的存储转发都是有效的。 （https://blog.stuffedcow.net/2014/01/x86-memory-disambiguation/）

（或者更好的是，push 0代替sub rsp,8 + mov，also a missed optimization，因为编译器不会费心寻找可能的情况。）

---

大概是在查找存储合并的优化过程之前，先确定堆栈帧中局部变量相对于彼此的位置。 （或者甚至在决定哪些本地变量可以保留在寄存器中以及哪些根本需要内存地址之前。）

GCC8 IIRC仅在最近才重新引入了商店合并（又称合并），但由于GCC2.95到GCC3（又是IIRC）的回归而被删除。 （我认为其他优化方法（例如，假设没有严格混叠的违反，以使更多的时间在寄存器中保留更多的var）更为有用）。因此它已经消失了数十年。

从一个POV中，您可以说自己很幸运，您完全可以合并任何商店（与结构成员和数组元素，这些元素早已被人们所熟知）。当然，从另一个POV来看，理想情况下，编译器应该使asm好。但实际上，错过优化是很常见的。幸运的是，我们拥有强大的CPU，具有超大范围的超标量无序执行，通常可以通过这种废话进行咀嚼，从而仍然看到即将到来的高速缓存未命中并快速存储，因此浪费的指令有时有时间在暗处执行其他瓶颈。并非总是如此，堵塞无序执行窗口中的空间绝不是一件好事。

相关：In x86-64 asm: is there a way of optimising two adjacent 32-bit stores / writes to memory if the source operands are two immediate values?涵盖了0以外的常量的一般情况，例如：最优asm是什么。 （仅在评论中讨论了数组与单独的本地变量之间的区别。）