Compiler generating extra memcpy, inconsistently depending on used types

[adrian17]

I'll preface with saying that the compiler was generating much worse code before 1.52, with up to 4 memcpy calls where there should have been one. So the LLVM 12 upgrade was great :)

Here's the sample:
https://godbolt.org/z/TdPdWqq6q

As you can see, both allocate_naive and allocate_ptr_write generate two memcpy calls (and significant stack usage). Manual unsafe optimization with allocate_separate_write generates a single memcpy. The same can be observed on x86_64: https://godbolt.org/z/6Mq9vKP3s

If I replace pub type Payload = RefCell<[u8; 1000]>; with just [u8; 1000], all three functions seem to generate good code with a single memcpy call: https://godbolt.org/z/8K7s8vbPa

Here's the weirdest part: with the original Payload, if I manually inline the MyStruct type parameter and turn MyStruct into a simple non-generic struct, it still generates bad code on wasm, but on x86_64 correctly optimized all functions into a single memcpy: https://godbolt.org/z/jsdrbGExW

Why does a seemingly-equivalent generic struct appears to generate worse code than a non-generic one?

[nikic]

IR: https://godbolt.org/z/d5PKx3b1d

At least at that point in time, the problem is that the first memcpy partially initializes the struct, without the first 7 bytes (why 7?) and then the second memcpy copies the whole struct. This makes it no longer a direct forward.

No idea why the generic type makes a difference here...

[adrian17]

No idea why the generic type makes a difference here...

Looks it results in a different layout. I simplified the case a bit to remove the RefCell:

pub struct Payload {
    borrow: isize,
    value: [u8; 1000],
}

pub struct MyStruct<T: ?Sized> {
    pub flags: u8,
    pub next: Option<i32>,
    pub value: T,
}

With the generic, llvm IR shows

%"MyStruct<Payload>" = type { { i32, i32 }, i8, [7 x i8], %Payload }

Without the generic, it puts Payload at the beginning, which probably happens to help the optimizer a bit (though to be honest, not sure if I like it from cache pov ;) ):

%MyStruct = type { %Payload, { i32, i32 }, i8, [7 x i8] }

[adrian17]

Also I just retested this issue on latest nightly:

As you can see, both allocate_naive and allocate_ptr_write generate two memcpy calls (and significant stack usage).

Still happening.

Here's the weirdest part: with the original Payload, if I manually inline the MyStruct type parameter and turn MyStruct into a simple non-generic struct, it still generates bad code on wasm, but on x86_64 correctly optimized all functions into a single memcpy

This now (since 1.65) optimizes better (to a single memcpy) both on wasm and x86_64. This is the case from the previous comment, where Rust reordered the big field to the beginning ot the struct.

[adrian17]

Oh, and for the record, the real-world use case is https://github.com/kyren/gc-arena , where allocate_naive is (was) more or less how Gc::allocate(context, some_big_object) was implemented.