为什么 std::optional<int> 的构造比 std::pair<int, bool> 更昂贵？

Question

考虑这两种可以表示“可选int”的方法：

using std_optional_int = std::optional<int>;
using my_optional_int = std::pair<int, bool>;

鉴于这两个功能...

auto get_std_optional_int() -> std_optional_int 
{
    return {42};
}

auto get_my_optional() -> my_optional_int 
{
    return {42, true};
}

...g++ trunk 和 clang++ trunk （使用 -std=c++17 -Ofast -fno-exceptions -fno-rtti） 生成以下程序集：

get_std_optional_int():
        mov     rax, rdi
        mov     DWORD PTR [rdi], 42
        mov     BYTE PTR [rdi+4], 1
        ret

get_my_optional():
        movabs  rax, 4294967338 // == 0x 0000 0001 0000 002a
        ret

live example on godbolt.org

---

为什么get_std_optional_int() 需要三个mov 指令，而get_my_optional() 只需要一个movabs？ 这是一个QoI 问题，还是std::optional 的问题？规范阻止了这种优化？

另外请注意，这些功能的用户可能会被完全优化出来：

volatile int a = 0;
volatile int b = 0;

int main()
{
    a = get_std_optional_int().value();
    b = get_my_optional().first;
}

...结果：

main:
        mov     DWORD PTR a[rip], 42
        xor     eax, eax
        mov     DWORD PTR b[rip], 42
        ret

Answer 1

libstdc++ 显然没有实现P0602 "variant and optional should propagate copy/move triviality"。您可以通过以下方式验证这一点：

static_assert(std::is_trivially_copyable_v<std::optional<int>>);

which fails for libstdc++, and passes for libc++ and the MSVC standard library（它确实需要一个合适的名称，因此我们不必将其称为“C++ 标准库的 MSVC 实现”或“MSVC STL”）。

当然，MSVC 仍然不会在寄存器中传递optional<int>，因为 MS ABI。

编辑：此问题已在 GCC 8 发行系列中得到修复。

Answer 2

为什么get_std_optional_int() 需要三个mov 指令，而 get_my_optional() 只需要一个movabs？

直接原因是optional是通过隐藏指针返回的，而pair是在寄存器中返回的。为什么呢？ SysV ABI 规范，3.2.3 参数传递部分说：

如果 C++ 对象具有非平凡的复制构造函数或 非平凡的析构函数，它通过不可见的引用传递。

整理出optional这个C++乱七八糟的东西并不容易，但似乎有一个non-trivial copy constructor at least in the optional_base class of the implementation I checked。

Answer 3

在Calling conventions for different C++ compilers and operating systems by Agner Fog 中，它说复制构造函数或析构函数阻止返回寄存器中的结构。这就解释了为什么optional 没有在寄存器中返回。

必须有其他东西阻止编译器进行存储合并（将比单词更窄的立即值的连续存储合并到更少的更宽存储中以减少指令数量）... 更新：gcc bug 82434 - -fstore-merging does not work reliably.

Answer 4

优化在技术上是允许的，即使std::is_trivially_copyable_v<std::optional<int>> 为假。但是，它可能需要编译器找到不合理程度的“聪明”。此外，对于使用std::optional 作为函数返回类型的特定情况，可能需要在链接时而不是编译时进行优化。

执行此优化不会影响任何（定义明确的）程序的可观察行为*，因此在as-if rule 下隐含允许。但是，由于其他答案中解释的原因，编译器尚未明确意识到这一事实，需要从头开始推断。行为静态分析是inherently difficult，所以编译器可能无法证明这种优化在所有情况下都是安全的。

假设编译器可以找到这个优化，那么它就需要改变这个函数的调用约定（即改变函数返回给定值的方式），这通常需要在链接时完成，因为调用约定会影响所有呼叫站点。或者，编译器可以完全内联函数，这在编译时可能会也可能不会。对于可简单复制的对象，这些步骤不是必需的，因此从这个意义上说，该标准确实抑制了优化并使优化复杂化。

std::is_trivially_copyable_v<std::optional<int>> 应该是真的。如果这是真的，编译器会更容易发现和执行这种优化。所以，回答你的问题：

这是一个 QoI 问题，还是 std::optional 的规范中的某些内容阻止了这种优化？

两者兼而有之。该规范使优化变得更难找到，并且实现不够“智能”，无法在这些约束下找到它。

---

* 假设你没有做过什么很奇怪的事情，比如#define int something_else。