Layout is computed even for (de)allocators that don't use it

When a program is using system malloc/free for the allocator, tracking of objects' size and alignment for deallocation is redundant and causes unnecessary code bloat.

It seems that it happens because __rust_dealloc is magic, and doesn't get inlined, so the optimizer can't see that its arguments are unused. There's this opaque layer of abstraction between allocations/deallocations in Rust and calls to malloc/free, which makes it not quite a zero-cost abstraction.


pub fn actual(_drop: Box<[u8; 123456]>) {

pub fn expected(drop: Box<[u8; 123456]>) {
    unsafe { free(Box::leak(drop).as_mut_ptr().cast()); }

Compiles to (godbolt link):

        mov     esi, 123456
        mov     edx, 1
        jmp     qword ptr [rip + __rust_dealloc@GOTPCREL]

        jmp     qword ptr [rip + free@GOTPCREL]

Note that Drop of a Box needlessly sets size and alignment of the allocation, because it can't know that this particular allocator implementation won't use it.

rest of the repro code
use std::alloc::*;

static A: Alloc = Alloc;

struct Alloc;

unsafe impl GlobalAlloc for Alloc {
    unsafe fn alloc(&self, _layout: Layout) -> *mut u8 { std::process::abort(); }

    unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) { std::process::abort(); }

    unsafe fn alloc_zeroed(&self, _layout: Layout) -> *mut u8 { std::process::abort(); }

    unsafe fn realloc(
        _ptr: *mut u8, 
        _layout: Layout, 
        _new_size: usize
    ) -> *mut u8 { std::process::abort(); }

extern "C" {
    fn free(_: *mut u8);

So it seems like there's a missed optimization opportunity here.

Maybe, but is that significant compared to the real work of the allocator?

It isn't for statically sized/aligned types, but it might be for dynamically sized/aligned types. If it's a currently supported DST, though, that's max an indirect load and a const add, or a mul and a const add.

So no, not really, I don't think so.

I'd be curious if LTO could see through __rust_dealloc?

I've tried -C lto and -C lto=fat, and it doesn't see through it on godbolt.

It's not just that there are a few unnecessary instructions per deallocation; it also misses the fact that dropping a Box<T> for any T is the exact same call to free (after dropping the T if it needed that). For example, the compiler shouldn't need to generate a new three-instruction function for every N that appears in Box<[u8; N]>: godbolt


The allocation functions are #[rustc_std_internal_symbol], so I think they're prohibited from being mucked with by LTO. I'm not sure why exactly though.

Building with LTO and -Z build-std permits this optimization. I wrote the following program:

pub fn actual(_drop: Box<[u8; 123456]>) {

pub fn main() {

And enabled LTO:

lto = true

Then compiled it with cargo +nightly rustc --release -Z build-std --target x86_64-unknown-linux-gnu -- --emit asm to get the following:

	.section	.text.actual,"ax",@progbits
	.globl	actual
	.p2align	4, 0x90
	.type	actual,@function
	jmpq	*free@GOTPCREL(%rip)
	.size	actual, .Lfunc_end1-actual

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.