-O3编译选项下std::move与RVO性能趋同的原因探究

先明确两个核心概念的本质：

• RVO（返回值优化）：编译器直接在调用方的栈帧上构造函数返回的对象，完全跳过拷贝/移动操作，属于零拷贝的激进优化
• std::move：只是把左值强制转为右值引用，触发对象的移动构造——哪怕移动构造开销很小，本质上还是有指针拷贝、资源转移的操作

为什么-O1和-O3差异这么大？ #

• 在-O1优化等级下，编译器只做基础优化：RVO能正常生效，但对std::move触发的移动构造没什么优化空间，所以RVO的零拷贝优势直接拉开20倍性能差
• 到了-O3，GCC会启用一堆激进优化，核心是上下文感知的代码消除与合并：
  • 首先是函数内联：如果你的测试函数被内联，编译器能看到整个调用链的完整逻辑，发现移动构造其实没有实际的“有效操作”（比如对象成员都是trivially movable的类型），会直接把移动构造的代码完全删掉，等价于直接在目标位置构造对象
  • 哪怕对象有非平凡的移动构造，GCC也会通过NRVO（命名返回值优化）的扩展逻辑，或者把移动构造的步骤合并到调用方的对象初始化流程里，消除额外的临时对象开销

加volatile后为什么还是持平？ #

volatile只是阻止编译器优化掉循环里的变量读写，但-O3的优化依然能作用在移动构造的逻辑上：

• 编译器虽然不能优化volatile变量的读写，但可以优化移动构造的过程——比如把移动构造的操作和目标对象的初始化合并，避免额外的临时对象创建与销毁
• 少数场景下，std::move明确标记了右值属性，反而让编译器能更精准地做优化，甚至比RVO路径略快一点

关键结论 #

编译器没有把std::move还原成RVO，而是通过内联、移动构造消除、上下文合并等更细粒度的优化手段，把std::move路径的额外开销完全抵消，最终达到和RVO零拷贝一样的性能效果。

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