这种“省略失败”是语言规定的吗？

Question

考虑以下代码：

#include <utility>
#include <string>

int bar() {
    std::pair<int, std::string> p { 
        123, "Hey... no small-string optimization for me please!" };
    return p.first;
}

_{(感谢@Jarod42 :-) ...)}

我希望该功能可以简单地实现：

bar():   
        mov eax, 123
        ret

但是，实现调用operator new()，用我的文字构造一个std::string，然后调用operator delete()。至少 - 这就是 gcc 9 和 clang 9 所做的 (GodBolt)。这是 clang 的输出：

bar():                                # @bar()
        push    rbx
        sub     rsp, 48
        mov     dword ptr [rsp + 8], 123
        lea     rax, [rsp + 32]
        mov     qword ptr [rsp + 16], rax
        mov     edi, 51
        call    operator new(unsigned long)
        mov     qword ptr [rsp + 16], rax
        mov     qword ptr [rsp + 32], 50
        movups  xmm0, xmmword ptr [rip + .L.str]
        movups  xmmword ptr [rax], xmm0
        movups  xmm0, xmmword ptr [rip + .L.str+16]
        movups  xmmword ptr [rax + 16], xmm0
        movups  xmm0, xmmword ptr [rip + .L.str+32]
        movups  xmmword ptr [rax + 32], xmm0
        mov     word ptr [rax + 48], 8549
        mov     qword ptr [rsp + 24], 50
        mov     byte ptr [rax + 50], 0
        mov     ebx, dword ptr [rsp + 8]
        mov     rdi, rax
        call    operator delete(void*)
        mov     eax, ebx
        add     rsp, 48
        pop     rbx
        ret
.L.str:
        .asciz  "Hey... no small-string optimization for me please!"

我的问题是：显然，编译器完全了解 bar() 内部发生的一切。为什么它不“删除”/优化字符串？更具体地说：

1. 在基本级别，代码介于 new() 和 delete() 之间，编译器知道 AFAICT 不会导致任何用处。
2. 其次，new() 和 delete() 调用自己。毕竟，标准 AFAIK 允许小字符串优化，所以即使 clang/gcc 没有选择使用它 - 它可以有；这意味着实际上不需要在那里调用new() 或delete()。

我特别感兴趣的是，这其中的哪一部分直接归因于语言标准，哪一部分是编译器的非最优性。

Answer 1

您的代码中没有任何内容代表"elision" as that term is commonly used in a C++ context。不允许编译器以“省略”为由从该代码中删除任何内容。

编译器必须删除该字符串的创建的唯一理由是基于“好像”规则。也就是说，字符串创建/销毁的行为是否对用户可见，因此无法删除？

由于它使用std::allocator 和标准字符特征，basic_string 构造和销毁本身不会被用户覆盖。因此，字符串的创建不是函数调用的可见副作用，因此可以根据“好像”规则删除。

但是，因为std::allocator::allocate 被指定为调用::operator new，并且operator new 是全局可替换的，所以有理由认为这是构造这样一个字符串的可见副作用。因此，编译器无法根据“好像”规则将其删除。

如果编译器知道你没有替换operator new，那么理论上它可以优化掉字符串。

这并不意味着任何特定的编译器会这样做。

Answer 2

问题是程序可以

int bar() {
    std::pair<int, std::string> p { 
        123, "Hey... no small-string optimization for me please!" };
    return p.first;
}

被有效优化为

int bar() {
    return 123;
}

tldr，是的，我想。

clang 使用 libc++：godbolt

关于std::string，标准说string.require/3

每个 basic_string 类型的对象都使用 Allocator 类型的对象根据需要为包含的 charT 对象分配和释放存储空间。

“根据需要”。 std::string 被允许决定何时使用分配器（我认为这是 SSO 有效的理由）。它的成员函数不强制分配。因此，分配可能会被省略。

Answer 3

根据此处各种答案和 cmets 的讨论，我现在针对 GCC 和 LLVM 提交了以下关于此问题的错误：

1. GCC bug 94293: [错过优化] new+delete of unused local string not removed

   最小测试用例 (GodBolt)：

   void foo() {
       int *p = new int[1];
       *p = 42;
       delete[] p;
   }
   

2. GCC bug 94294: [错过优化] 填充本地字符串的无用语句未删除

   最小测试用例（GodBolt）：

   void foo() {
       std::string s { "This is not a small string" };
   }
   

3. LLVM bug 45287: [错过优化] 未能删除未使用的 libstdc++ std::string。

   最小测试用例（GodBolt）：

   void foo() {
       std::string s { "This is not a small string" };
   }
   

感谢：@JeffGarret、@NicolBolas、@Jarod42、Marc Glisse。

2021 年 8 月更新：使用最新版本的 clang++、g++ 和 libstc++，所有这些最小的测试用例都如预期的那样避开了内存分配。 clang++ 对问题中的 OP 程序也有这种行为，但 GCC 仍然分配和解除分配。