GCC编译的字符交换函数是否存在优化遗漏？

我自行编写了Linux x86-64架构下的字符交换汇编函数，代码如下：

swap: ; written by me
    mov al, byte [rdi]
    xchg byte [rsi], al
    mov byte [rdi], al
    ret

出于好奇，我将对应的C交换函数用GCC -O3编译，通过objconv得到其汇编代码：

swap:   ; written by GCC -O3
        endbr64                                         ; 0000 _ F3: 0F 1E. FA
        movzx   eax, byte [rdi]                         ; 0004 _ 0F B6. 07
        movzx   edx, byte [rsi]                         ; 0007 _ 0F B6. 16
        mov     byte [rdi], dl                          ; 000A _ 88. 17
        mov     byte [rsi], al                          ; 000C _ 88. 06
        ret                                             ; 000E _ C3

GCC生成的代码可正常工作，但我的手写汇编代码更短，请问这是否属于GCC的优化遗漏？若属实，为何会出现这种情况？

解答 #

• 这不算GCC的优化遗漏，核心原因是代码长度不等于执行性能：

  • 你手写代码里的xchg byte [rsi], al指令，当操作数包含内存时，会隐含触发LOCK前缀（即使是单线程场景），这会导致CPU锁定内存总线，产生额外的同步开销，大幅降低执行效率。现代CPU对这种总线锁的处理成本很高，远不如普通的内存读写指令高效。
  • GCC生成的四个mov指令序列，都是普通的无锁内存操作，CPU可以通过乱序执行、内存预取等优化手段提升吞吐量，实际运行速度比你的手写代码快很多。

• GCC的优化目标是实际执行性能而非代码短小。编译器的优化器会优先选择延迟更低、吞吐量更高的指令组合，哪怕最终代码长度更长。短代码往往只是看起来简洁，但在现代CPU复杂的流水线设计下，未必是最优选择。

• 另外，GCC生成的endbr64是控制流完整性（CFI）的安全指令，属于默认开启的安全编译特性，和优化无关。如果关闭对应安全选项（比如-fcf-protection=none），这条指令会消失，但核心的mov序列依然会被保留，因为这是性能更优的实现。

• 你的手写代码虽然短，但只有在极端追求代码字节数（比如某些嵌入式场景或壳代码）时才有意义，在常规应用中，GCC生成的代码在性能和安全性上都更优。

内容的提问来源于stack exchange，提问作者avighnac