`String::new()` is slower than `"".to_string()`

I tried this code:

pub fn a() -> String {
    String::new()
}

pub fn b() -> String {
    "".to_string()
}

I expected to see this happen: both functions contain identical code.

Instead, this happened: https://rust.godbolt.org/z/P53MMG4W6.

For String::new() it does one more instruction: mov rcx, qword ptr [rip + .L__unnamed_1]. This rcx is then read further below at mov qword ptr [rdi], rcx.
The "".to_string() version however does not do this extra step and immediately reads from a constant: mov qword ptr [rdi], 1.
This means that String::new() does slightly more work than "".to_string() but I expect them to be identical.

Before 1.52.0 the functions generated identical code: https://rust.godbolt.org/z/8647E6YhY.

oli noted the following:

The problem is probably because it copies its value from the constant

rust/library/alloc/src/raw_vec.rs

Line 64 in d620ae1

pub const NEW: Self = Self::new();

instead of immediately creating the appropriate value

Meta

This currently happens on nightly.

@rustbot label regression-untriaged

[JohnTitor]

Regressed since 1.52.0, between nightly-2021-03-04 and nightly-2021-03-05 so I assume it's caused (revealed?) by #81451.

[cynecx]

Reduced llvm-ir:

target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

%"std::string::String" = type { [0 x i64], %"std::vec::Vec<u8>", [0 x i64] }
%"std::vec::Vec<u8>" = type { [0 x i64], { i8*, i64 }, [0 x i64], i64, [0 x i64] }

@0 = private unnamed_addr constant <{ [16 x i8] }> <{ [16 x i8] c"\01\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00" }>, align 8

define void @abc(%"std::string::String"* %0) unnamed_addr {
start:
  %1 = load i8*, i8** bitcast (<{ [16 x i8] }>* @0 to i8**), align 8
  %ptr = bitcast %"std::string::String"* %0 to i8**
  store i8* %1, i8** %ptr, align 8
  ret void
}

; This works by replacing the pointer type with an integral type

define void @cba(%"std::string::String"* %0) unnamed_addr {
start:
  %1 = load i64, i64* bitcast (<{ [16 x i8] }>* @0 to i64*), align 8
  %ptr = bitcast %"std::string::String"* %0 to i64*
  store i64 %1, i64* %ptr, align 8
  ret void
}

LLVM fails to figure out that the load can be replaced with a constant (Probably because of the load bitcast pattern for pointer types).

[klensy]

It isn't only in String main thing there in const. The same can be seen in vec:

pub fn foo()->Vec<u8>{
    vec![]
}

pub fn foo()->Vec<u8>{
    vec![].clone()
}

example::foo:
        mov     rax, rdi
        mov     rcx, qword ptr [rip + .L__unnamed_1]
        mov     qword ptr [rdi], rcx
        xorps   xmm0, xmm0
        movups  xmmword ptr [rdi + 8], xmm0
        ret

.L__unnamed_1:
        .asciz  "\001\000\000\000\000\000\000\000\000\000\000\000\000\000\000"


example::foo:
        mov     rax, rdi
        mov     qword ptr [rdi], 1
        xorps   xmm0, xmm0
        movups  xmmword ptr [rdi + 8], xmm0
        ret

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high