Avoid picture primitive copies via VecHelper

[kvark]

This is a successor of #3360 that avoids the borrow checker dance via RAII
Addresses part of #3358

---

This change is 

[jrmuizel]

"and ideally construct the element in place"

[jrmuizel]

Maybe add:
// writing is safe because alloc() ensured enough capacity and Allocation holds a mutable borrow to prevent anyone else from breaking this invariant.

[emilio]

Are you sure this actually avoids the memcpy / memmove? At least for self arguments a bit back we couldn't work around it like this, see rust-lang/rust#42763.

[kvark]

Confirmed in playground. In fn foo() changing the push(xxx) to alloc().init(xxx) removes the memcpy.

[jrmuizel]

I filed rust-lang/rust#56333 for a problem contributing to the first example not working well in the playground.

[jrmuizel]

It looks like SmallVec also causes this to not work. I filed rust-lang/rust#56356 about that.

[jrmuizel]

It'd be nice if this only ran if profiling was on.

[kvark]

I'm not able to use @jrmuizel 's tool that find memcopies, since IR validation fails on webrender crate. However, I tried to reproduce this in playground, and in both cases (vec.push(x) and vec.alloc().init(x)) the compiler created the data on the stack first and then issued a single memcpy, so it doesn't appear to be fixing the copy.

Is my playground experiment incorrect? Otherwise, what assumptions are wrong?

[bors-servo]

☔ The latest upstream changes (presumably #3359) made this pull request unmergeable. Please resolve the merge conflicts.

[jrmuizel]

If you use an enum containing an array instead of an array and initialize with a small enum variant the copy is elided in your example

[kvark]

@jrmuizel indeed, I confirmed it with the playground experiment.
Therefore, we should proceed with this PR.

[kvark]

@bors-servo r=jrmuizel

[bors-servo]

📌 Commit d680e32 has been approved by jrmuizel

[bors-servo]

⌛ Testing commit d680e32 with merge be65949...

[bors-servo]

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: jrmuizel
Pushing be65949 to master...

[jrmuizel]

It looks like this may not have worked:

memcpy of 1592 in _ZN9webrender22display_list_flattener20DisplayListFlattener20pop_stacking_context17hc7e8ce6ec929e9eaE @
  write<webrender::picture::PicturePrimitive> /rustc/6f93e93af6f823948cc13d2938957757c6486d88/src/libcore/ptr.rs:739
  init<webrender::picture::PicturePrimitive> webrender/src/util.rs:33
  pop_stacking_context webrender/src/display_list_flattener.rs:1220
memcpy of 1592 in _ZN9webrender22display_list_flattener20DisplayListFlattener20pop_stacking_context17hc7e8ce6ec929e9eaE @
  write<webrender::picture::PicturePrimitive> /rustc/6f93e93af6f823948cc13d2938957757c6486d88/src/libcore/ptr.rs:739
  init<webrender::picture::PicturePrimitive> webrender/src/util.rs:33
  pop_stacking_context webrender/src/display_list_flattener.rs:1187
memcpy of 1592 in _ZN9webrender22display_list_flattener20DisplayListFlattener21push_stacking_context17h500d71065754d89aE @
  write<webrender::picture::PicturePrimitive> /rustc/6f93e93af6f823948cc13d2938957757c6486d88/src/libcore/ptr.rs:739
  init<webrender::picture::PicturePrimitive> webrender/src/util.rs:33
  cut_flat_item_sequence webrender/src/display_list_flattener.rs:2207
  push_stacking_context webrender/src/display_list_flattener.rs:994
memcpy of 1592 in _ZN9webrender22display_list_flattener20DisplayListFlattener20pop_stacking_context17hc7e8ce6ec929e9eaE @
  write<webrender::picture::PicturePrimitive> /rustc/6f93e93af6f823948cc13d2938957757c6486d88/src/libcore/ptr.rs:739
  init<webrender::picture::PicturePrimitive> webrender/src/util.rs:33
  pop_stacking_context webrender/src/display_list_flattener.rs:1158
memcpy of 1592 in _ZN9webrender22display_list_flattener20DisplayListFlattener12flatten_item17hfd2b2318f8c75547E @
  write<webrender::picture::PicturePrimitive> /rustc/6f93e93af6f823948cc13d2938957757c6486d88/src/libcore/ptr.rs:739
  init<webrender::picture::PicturePrimitive> webrender/src/util.rs:33
  pop_all_shadows webrender/src/display_list_flattener.rs:1564
  flatten_item webrender/src/display_list_flattener.rs:789
memcpy of 1592 in _ZN9webrender22display_list_flattener20DisplayListFlattener20pop_stacking_context17hc7e8ce6ec929e9eaE @
  write<webrender::picture::PicturePrimitive> /rustc/6f93e93af6f823948cc13d2938957757c6486d88/src/libcore/ptr.rs:739
  init<webrender::picture::PicturePrimitive> webrender/src/util.rs:33
  pop_stacking_context webrender/src/display_list_flattener.rs:1117

I wonder if llvm gets sad the enum variant is too big.

[jrmuizel]

It looks like SmallVec is contributing to the sadness:

#![crate_type = "lib"]

extern crate smallvec;

use smallvec::SmallVec;

#[derive(Default)]
pub struct L {
    a: SmallVec<[f64; 16]>,
    b: SmallVec<[f64; 16]>,
    c: SmallVec<[f64; 16]>
}

pub struct Allocation<T> {
    f: *mut T,
}
use std::ptr;

impl<T> Allocation<T> {
    pub fn init(self, value: T) {
        unsafe { ptr::write(self.f, value) };
    }
}

#[inline(never)]
pub fn bar(a: Allocation<L>) {
    a.init(L{a: SmallVec::new(), b: SmallVec::new(), c: SmallVec::new()});
}

compiles to

playground::bar:
	pushq	%rbx
	subq	$720, %rsp
	movq	%rdi, %rbx
	xorps	%xmm0, %xmm0
	movaps	%xmm0, 288(%rsp)
	movaps	%xmm0, (%rsp)
	movaps	%xmm0, 144(%rsp)
	leaq	432(%rsp), %rdi
	movq	%rsp, %rsi
	movl	$144, %edx
	callq	memcpy@PLT
	leaq	576(%rsp), %rdi
	leaq	144(%rsp), %rsi
	movl	$144, %edx
	callq	memcpy@PLT
	leaq	288(%rsp), %rsi
	movl	$432, %edx
	movq	%rbx, %rdi
	callq	memcpy@PLT
	addq	$720, %rsp
	popq	%rbx
	retq

[jrmuizel]

The smallvec example now generates better code with Nightly:

playground::bar: # @playground::bar
# %bb.0:
	subq	$440, %rsp              # imm = 0x1B8
	xorps	%xmm0, %xmm0
	movaps	%xmm0, (%rsp)
	movaps	%xmm0, 144(%rsp)
	movaps	%xmm0, 288(%rsp)
	movq	%rsp, %rsi
	movl	$432, %edx              # imm = 0x1B0
	callq	*memcpy@GOTPCREL(%rip)
	addq	$440, %rsp              # imm = 0x1B8
	retq

However it looks like there's still an extra memcpy

[jrmuizel]

I filed a follow up at rust-lang/rust#58082