test that the phi node got eliminated

Author: the8472

library/alloc/src/slice.rs

@@ -68,6 +68,7 @@ use crate::borrow::ToOwned;
 use crate::boxed::Box;
 use crate::vec::Vec;
 
+
 impl<T> [T] {
     /// Sorts the slice in ascending order, preserving initial order of equal elements.
     ///
@@ -446,6 +447,12 @@ impl<T> [T] {
         impl<T: Copy> ConvertVec for T {
             #[inline]
             fn to_vec<A: Allocator>(s: &[Self], alloc: A) -> Vec<Self, A> {
+                if s.is_empty() {
+                    // The early return is not necessary for correctness, but it helps
+                    // LLVM by avoiding phi nodes flowing into memcpy.
+                    // See codegen/lib-optimizations/append-elements.rs
+                    return Vec::new_in(alloc);
+                }
                 let mut v = Vec::with_capacity_in(s.len(), alloc);
                 // SAFETY:
                 // allocated above with the capacity of `s`, and initialize to `s.len()` in

library/alloc/src/vec/mod.rs

@@ -2590,11 +2590,9 @@ impl<T, A: Allocator> Vec<T, A> {
     unsafe fn append_elements(&mut self, other: *const [T]) {
         let count = other.len();
         if count == 0 {
-            // The early return is not necessary for correctness, but in cases
-            // where LLVM sees all the way to the allocation site of `other`
-            // this can avoid a phi-node merging the two different pointers
-            // when zero-length allocations are special-cased.
-            // That in turn can enable more optimizations around the memcpy below.
+            // The early return is not necessary for correctness, but it helps
+            // LLVM by avoiding phi nodes flowing into memcpy.
+            // See codegen/lib-optimizations/append-elements.rs
             return;
         }
         self.reserve(count);

tests/codegen/lib-optimizations/append-elements.rs

@@ -0,0 +1,37 @@
+//@ compile-flags: -O -Zmerge-functions=disabled
+#![crate_type = "lib"]
+
+//! Check that pointer flowing into vec.append comes straight from an allocation
+//! and not through a phi node that merges the allocation and zero-length cases.
+//! With this and https://github.com/llvm/llvm-project/pull/110280 the intermediate
+//! allocation should be optimized away in the future.
+
+// CHECK-LABEL: @vec_append_with_temp_alloc
+#[no_mangle]
+pub fn vec_append_with_temp_alloc(dst: &mut Vec<u8>, src: &[u8]) {
+    // CHECK: %[[TEMP:.+]] = tail call noalias noundef ptr @{{.*}}__rust_alloc
+
+    // First memcpy, it uses the src pointer directly
+    // CHECK: call void @llvm.memcpy.{{.*}}%src.0
+    let temp = src.to_vec();
+
+    // final memcpy to destination
+    // CHECK: call void @llvm.memcpy.{{.*}}%dst.i{{.*}}%[[TEMP]]
+    dst.extend(&temp);
+    // CHECK: ret
+}
+
+// CHECK-LABEL: @string_append_with_temp_alloc
+#[no_mangle]
+pub fn string_append_with_temp_alloc(dst: &mut String, src: &str) {
+    // CHECK: %[[TEMP:.+]] = tail call noalias noundef ptr @__rust_alloc
+
+    // First memcpy, it uses the src pointer directly
+    // CHECK: call void @llvm.memcpy.{{.*}}%src.0
+    let temp = src.to_string();
+
+    // final memcpy to destination
+    // CHECK: call void @llvm.memcpy.{{.*}}%dst.i{{.*}}%[[TEMP]]
+    dst.push_str(&temp);
+    // CHECK: ret
+}