Change:
<ins> // min-llvm-version: 15.0 // compile-flags: -C opt-level=3 -Z merge-functions=disabled // The below two functions ensure that both `String::new()` and `"".to_string()` // produce the identical code. #![crate_type = "lib"] // CHECK-LABEL: define void @string_new #[no_mangle] pub fn string_new() -> String { // CHECK-NOT: load i8 // CHECK: store i{{32|64}} // CHECK-NEXT: getelementptr // CHECK-NEXT: store ptr // CHECK-NEXT: getelementptr // CHECK-NEXT: store i{{32|64}} // CHECK-NEXT: ret void String::new() } // CHECK-LABEL: define void @empty_to_string #[no_mangle] pub fn empty_to_string() -> String { // CHECK-NOT: load i8 // CHECK: store i{{32|64}} // CHECK-NEXT: getelementptr // CHECK-NEXT: store ptr // CHECK-NEXT: getelementptr // CHECK-NEXT: store i{{32|64}} // CHECK-NEXT: ret void "".to_string() } // The below two functions ensure that both `vec![]` and `vec![].clone()` // produce the identical code. // CHECK-LABEL: @empty_vec #[no_mangle] pub fn empty_vec() -> Vec<u8> { // CHECK: store i{{32|64}} // CHECK-NOT: load i8 // CHECK-NEXT: getelementptr // CHECK-NEXT: store ptr // CHECK-NEXT: getelementptr // CHECK-NEXT: store i{{32|64}} // CHECK-NEXT: ret void vec![] } // CHECK-LABEL: @empty_vec_clone #[no_mangle] pub fn empty_vec_clone() -> Vec<u8> { // CHECK: store i{{32|64}} // CHECK-NOT: load i8 // CHECK-NEXT: getelementptr // CHECK-NEXT: store ptr // CHECK-NEXT: getelementptr // CHECK-NEXT: store i{{32|64}} // CHECK-NEXT: ret void vec![].clone() } </ins>

Discussion:
I tried this code: I expected to see this happen: both functions contain identical code. Instead, this happened: For it does one more instruction: . This is then read further below at . The version however does not do this extra step and immediately reads from a constant: . This means that does slightly more work than but I expect them to be identical. Before 1.52.0 the functions generated identical code: oli noted the following: This currently happens on nightly.
label regression-untriaged
Regressed since 1.52.0, between nightly-2021-03-04 and nightly-2021-03-05 so I assume it's caused (revealed?) by .
Reduced llvm-ir: LLVM fails to figure out that the load can be replaced with a constant (Probably because of the pattern for pointer types).
It isn't only in main thing there in const. The same can be seen in vec:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
This can be somewhat solved by using directly, without hack, i.e. for Vec: instead of but i been hit by Tried solving this by placing in some places, but no luck. Any suggestions?
Seems like you hit .
is , so maybe not ? It could be because these stability changes are seen by the bootstrap compiler and not your own version of . There are a few examples of attributes needing to be ed out until a new version of the compiler with your changes is used for bootstrap (and then these attributes are removed when that happens.) Depending on whether you need to target the bootstrap compiler, or to "temporarily hide" your changes from it, it can look like .
Tried to change Vec to: and RawVec to with adding But this clearly wrong (tried few permutations of cfg's), as error the same.
Asking about how to handle this on zulip, e.g. in the , would probably be best then.
Found workaround, but this bloats rcgu size a lot, sadly.
Fixed upstream by
I assume that this will make its way into Rust with LLVM 14? Or will it become a patch release?
This will be part of the LLVM 14 upgrade.
Fixed by , but test should be , to check regressions in future.