c++ - 分配顺序产生不同的装配

Question

该实验是使用GCC 6.3完成的。有两个函数，唯一的区别在于我们在结构中分配i32和i16的顺序。我们假设这两个函数应该产生相同的程序集。然而，这种情况并非如此。 “不良”功能会产生更多指令。谁能解释为什么会这样？

#include <inttypes.h>

union pack {
    struct {
        int32_t i32;
        int16_t i16;
    };
    void *ptr;
};
static_assert(sizeof(pack)==8, "what?");

void *bad(const int32_t i32, const int16_t i16) { 
    pack p;
    p.i32 = i32;
    p.i16 = i16;
    return p.ptr;
}

void *good(const int32_t i32, const int16_t i16) { 
    pack p;
    p.i16 = i16;
    p.i32 = i32;
    return p.ptr;
}

...

bad(int, short):
        movzx   eax, si
        sal     rax, 32
        mov     rsi, rax
        mov     eax, edi
        or      rax, rsi
        ret
good(int, short):
        movzx   eax, si
        mov     edi, edi
        sal     rax, 32
        or      rax, rdi
        ret

编译器标志为-O3 -fno-rtti -std = c++ 14

Answer 1

这是/曾经在GCC10.2和更早版本中错过了优化。在当前的每晚GCC 版本中，该问题似乎已得到修复，因此无需报告GCC的bugzilla的未优化优化错误。 (https://gcc.gnu.org/bugzilla/)。看起来它最初是作为从GCC4.8到GCC4.9的回归出现的。 (Godbolt)

# GCC11-dev nightly build
# actually *better* than "good", avoiding a mov-elimination missed opt.
bad(int, short):
        movzx   esi, si          # mov-elimination never works for 16->32 movzx
        mov     eax, edi         # mov-elimination works between different regs
        sal     rsi, 32
        or      rax, rsi
        ret

是的，只要启用了优化，或者至少希望so1 ，您通常希望C++能够以基本相同的方式实现相同的逻辑，以相同的方式编译到相同的asm。通常，您可以希望不会有无缘无故的无用优化，这些优化无缘无故浪费指令(而不是简单地选择其他实现策略)，但不幸的是，这也不总是正确的。
通常，对于编译器而言，编写同一对象的不同部分然后读取整个对象是棘手的，因此，当您以不同的顺序编写完整对象的不同部分时，看到不同的asm并不感到震惊。
请注意，关于bad asm并没有任何“智能”，它只是在执行冗余的mov指令。必须接受固定寄存器的输入并在另一个特定的硬寄存器中产生输出才能满足调用约定，这是GCC的寄存器分配器不足为奇的地方:浪费了mov错过的优化在微型函数中比在大型函数中更常见功能。
如果您真的很好奇，可以深入研究GCC转换成的GIMPLE和RTL内部表示形式。 (Godbolt具有一个GCC树转储 Pane 来帮助您解决此问题。)
脚注1:或者至少希望，但是错过优化的错误确实会在现实生活中发生。当您发现它们时，请报告它们，以防GCC或LLVM开发人员可以轻松地教他们避免这种情况。编译器是复杂的机器，需要多次通过。通常，直到其他优化通道更改为执行其他操作时，优化器的一部分才刚刚发生过，这为该代码的作者在编写/调整时没有考虑的情况暴露了糟糕的最终结果它可以改善其他情况。

请注意，尽管有注释中的抱怨，但这里没有“未定义行为”:C和C++ defines the behaviour of union type-punning in C89 and C++的GNU方言，不仅在C99中，而且在以后像ISO C一样。实现可以自由定义ISO C++未定义的任何行为。
从技术上讲，这是一个未初始化的读取操作，因为尚未将void*对象的高2个字节写入pack p中。但是用pack p = {.ptr=0};修复它并没有帮助。 (并且不会更改asm； GCC恰好已经将padding设为零，因为这很方便)。

还请注意，问题中的两个版本的效率均不如可能:
(从GCC4.8或GCC11-trunk输出的bad避免了浪费的mov看起来对于该策略选择是最佳的。)
在Intel和AMD上都使用mov edi,edi defeats mov-elimination，因此该指令的周期延迟为1，而不是0，并消耗了后端µop。选择一个不同的寄存器进行零扩展将更便宜。读完SI之后，我们甚至可以选择RSI，但是任何 call 密集的寄存器都可以使用。

hand_written:
    movzx  eax, si    # 16->32 can't be eliminated, only 8->32 and 32->32 mov
    shl    rax, 32
    mov    ecx, edi   # zero-extend into a different reg with 0 latency
    or     rax, rcx
    ret

或者，如果在Intel上针对代码大小或吞吐量进行了优化(低µop计数，而不是低延迟)，则shld是一个选项:Intel上为1 µop / 3c延迟，而Zen上为6 µops(尽管也是3c延迟)。 (https://uops.info/和https://agner.org/optimize/)

minimal_uops_worse_latency:  # also more uops on AMD.
    movzx  eax, si
    shl    rdi, 32              # int32 bits to the top of RDI
    shld   rax, rdi, 32         # shift the high 32 bits of RDI into RAX.
    ret

如果以另一种方式对结构进行了排序(中间有填充)，则可以执行涉及mov ax, si的操作以合并到RAX中。这对于非英特尔公司以及在Haswell及更高版本上可能是有效的，后者除了AH之类的高8位寄存器外，不进行部分寄存器重命名。

给定未读的UB，您可以将其编译为几乎所有内容，包括ret或ud2。或略微降低攻击性，您可以对其进行编译以仅为结构的填充部分(最后2个字节)留下垃圾。

high_garbage:
    shl    rsi, 32    # leaving high garbage = incoming high half of ESI
    mov    eax, edi   # zero-extend into RAX
    or     rax, rsi
    ret

请注意，x86-64系统V ABI((实际上依赖于此)的非官方扩展是将窄args符号扩展或零扩展为32位。因此，指针的高2个字节将代替符号位，而不是零。 (实际上可以保证它是x86-64上的规范48位虚拟地址!)