Specialized slice::fill implementations are not inlined

[steffahn]

Specialized slice::fill implementations are not inlined even though they would compile down to pretty much just a single memset-call.

The bar function below represents manual inlining of the implementation of fill.

use core::ptr::write_bytes;

pub fn foo(slice: &mut [u8]) {
    slice.fill(42);
}

pub fn bar(slice: &mut [u8]) {
    unsafe {
        let ptr = slice.as_mut_ptr();
        let len = slice.len();
        write_bytes(ptr, 0_u8, len);
    }
}

(Playground)

    Finished release [optimized] target(s) in 0.83s
   
---------- Result ----------

playground::foo: # @playground::foo
# %bb.0:
	movl	$42, %edx
	jmpq	*<[u8] as core::slice::specialize::SpecFill<u8>>::spec_fill@GOTPCREL(%rip) # TAILCALL
                                        # -- End function

playground::bar: # @playground::bar
# %bb.0:
	movq	%rsi, %rdx
	xorl	%esi, %esi
	jmpq	*memset@GOTPCREL(%rip)          # TAILCALL
                                        # -- End function

I haven’t tested it in any way, but I suspect that this can be fixed by marking the fill specialized implementations for u8, i8, and bool as #[inline].

[steffahn]

@rustbot modify labels: C-enhancement, T-libs-impl, I-slow, E-easy

[the8472]

@rustbot claim

[slightlyoutofphase]

Don't you need at the very least #[inline] (but not necessarily #[inline(always)]) to actually guarantee cross-crate-inlining eligibility with the default no-LTO release profile? It'd certainly make sense to add that to all of the impls in this file IMO.

[the8472]

It being generic is sufficient for being eligible because the monomorphized function is only created in the consuming crate once all the generics have been filled in. Adding #[inline] on top just encourages it further.