GCC generates test for nonzeroness even if the zero value is guaranteed

Question

Consider the following class, created mainly for benchmarking purposes:

class String {
  char* data_; 
public:
  String(const char* arg = "") : data_(new char[strlen(arg) + 1]) { strcpy(data_, arg); }
  String(const String& other) : String(other.data_) { }
  String(String&& other) noexcept : data_(other.data_) { other.data_ = nullptr; }
  String& operator=(String other) noexcept { swap(other); return *this; }  
  ~String() { delete[] data_; }
  void swap(String& rhs) noexcept { std::swap(data_, rhs.data_); }
  const char* data() const { return data_; }   
};
void swap(String& lhs, String& rhs) noexcept { lhs.swap(rhs); }

I am trying to compare the efficiency of swapping of two of its instances with custom swap and std::swap. For custom swap, GCC 8.2 (-O2) generates the following x86_64 assembly:

mov     rax, QWORD PTR [rdi]
mov     rdx, QWORD PTR [rsi]
mov     QWORD PTR [rdi], rdx
mov     QWORD PTR [rsi], rax
ret

which exactly matches swapping of two pointers. However, for std::swap, the generated assembly is:

  mov     rdx, QWORD PTR [rsi]
  mov     QWORD PTR [rsi], 0    // (A)
  mov     rax, QWORD PTR [rdi]
  mov     QWORD PTR [rdi], 0    // (1)
  mov     QWORD PTR [rsi], rax  // (B)
  mov     rax, QWORD PTR [rdi]  // (2)
  mov     QWORD PTR [rdi], rdx
  test    rax, rax              // (3)
  je      .L3
  mov     rdi, rax
  jmp     operator delete[](void*) 
.L3:
  ret

What I am curious about is why GCC generates such inefficient code. The instruction (1) sets [rdi] to zero. That zero is then loaded into rax (2). And then, rax is tested (3) whether or not operator delete should be called.

Why GCC tests rax if it is guaranteed to be zero? It seems to be a pretty simple case for the optimizer to avoid this test.

Godbolt demo: https://godbolt.org/z/WNm2if

---

Another source of inefficiency is that 0 is written to [rsi] first (A) and then it is overwritten with another value (B).

Bottom line: I would expect a compiler to generate the same machine code for std::swap as well as for custom swap, which does not happen. This indicates that writing custom swapping functions makes sense even for classes that support move semantics.

Answer 1

The instruction (1) sets [rdi] to zero. That zero is then loaded into rax (2).

This isn't always the case, because rax is copied to [rsi] first, and there is no guarantee that [rsi] and [rdi] are different. So gcc cannot make this assumption, and it doesn't. Neither does any other compiler.

Edit (extracted from the comments): If [rsi] and [rdi] are the same, then [rdi] contains zero anyway (a "different" one that comes from Instruction A) and if they partially overlap, that's undefined behaviour and the compiler can assume it will never happen. But the optimiser doesn't see this far.

This indicates that writing custom swapping functions makes sense even for classes that support move semantics.

Write separate copy assignment and move assignment operators, and the problem goes away. This newfangled pass-by-copy assignment operator looks like a brilliant idea, but as we can see, compilers may have some trouble optimising it away---and other compilers have a lot of trouble. Just look at the assembly generated by MSVC or clang.

Answer 2

The reasoning is most likely that while the first code sample generates efficient code because there are no abstractions between the program and the desired executable (you are programming the swap).

In the second case, swap is a member of the standard library. which might have this check as a safety measure, which GCC simply did not optimize out.

Basically, I believe the standard library must have such safety checks. Writing code for a specific task will yield code optimized to the specific task. You do not need to cover all the possible cases that it might make sense to use swap.