LLVM not optimizing out heap allocations when using a custom allocator

[izagawd]

I tried this code:

#[global_allocator]
static GLOBAL: MiMalloc = MiMalloc;

#[unsafe(no_mangle)]
pub fn test_heap_alloc_optimization(){
    Box::new(4);
}

On Windows 11

I expected it to optimize out the heap allocation since the Box is not used anywhere, but the heap allocation is actually happening

Here is the assembly code.

test_heap_alloc_optimization:
.seh_proc test_heap_alloc_optimization
	subq	$40, %rsp
	.seh_stackalloc 40
	.seh_endprologue
	callq	_RNvCs5Yz3s5T3wso_7___rustc35___rust_no_alloc_shim_is_unstable_v2
	movl	$4, %ecx
	movl	$4, %edx
	callq	mi_malloc_aligned
	testq	%rax, %rax
	je	.LBB9_1
	movl	$4, (%rax)
	movq	%rax, %rcx
	.seh_startepilogue
	addq	$40, %rsp
	.seh_endepilogue
	jmp	mi_free
.LBB9_1:
	movl	$4, %ecx
	movl	$4, %edx
	callq	_ZN5alloc5alloc18handle_alloc_error17h26b165d14d93d00aE
	int3
	.seh_endproc

I believe the allocation is happening at mi_maloc_aligned.

Here is what I got when mimalloc was removed from being the global allocator (so now its using default allocator)

test_heap_alloc_optimization:
	jmp	_RNvCs5Yz3s5T3wso_7___rustc35___rust_no_alloc_shim_is_unstable_v2

Now there is no heap allocation happening, as it should be.

Meta

rustc 1.93.0-nightly (6647be936 2025-11-09)
binary: rustc
commit-hash: 6647be93640686a2a443a49f15c3390b68c8b5dd
commit-date: 2025-11-09
host: x86_64-pc-windows-msvc
release: 1.93.0-nightly
LLVM version: 21.1.3

On Linux (Debian)

I also tried it on linux, and still, heap allocation is happening

test_heap_alloc_optimization:
    .cfi_startproc
    pushq    %rax
    .cfi_def_cfa_offset 16
    callq    *_RNvCsfHF5UXtEvMp_7___rustc35___rust_no_alloc_shim_is_unstable_v2@GOTPCREL(%rip)
    movl    $4, %edi
    movl    $4, %esi
    callq    *mi_malloc_aligned@GOTPCREL(%rip)
    testq    %rax, %rax
    je    .LBB9_1
    movl    $4, (%rax)
    movq    %rax, %rdi
    popq    %rax
    .cfi_def_cfa_offset 8
    jmpq    *mi_free@GOTPCREL(%rip)

I then tried it out with jemalloc, using the tikv-jemallocator crate

test_heap_alloc_optimization:
	.cfi_startproc
	pushq	%rax
	.cfi_def_cfa_offset 16
	callq	*_RNvCsfHF5UXtEvMp_7___rustc35___rust_no_alloc_shim_is_unstable_v2@GOTPCREL(%rip)
	movl	$4, %edi
	callq	*_rjem_malloc@GOTPCREL(%rip)
	testq	%rax, %rax
	je	.LBB9_1
	movl	$4, (%rax)
	movl	$4, %esi
	movq	%rax, %rdi
	xorl	%edx, %edx
	popq	%rax
	.cfi_def_cfa_offset 8
	jmpq	*_rjem_sdallocx@GOTPCREL(%rip)
.LBB9_1:
	.cfi_def_cfa_offset 16
	movl	$4, %edi
	movl	$4, %esi
	callq	*_ZN5alloc5alloc18handle_alloc_error17h2d947eb22614166fE@GOTPCREL(%rip)
.Lfunc_end9:
	.size	test_heap_alloc_optimization, .Lfunc_end9-test_heap_alloc_optimization
	.cfi_endproc

Still, there is a heap allocation, at callq *_rjem_malloc@GOTPCREL(%rip) I believe

Meta

rustc 1.93.0-nightly (94b49fd99 2025-11-22)
binary: rustc
commit-hash: 94b49fd998d6723e0a9240a7cff5f9df37b84dd8
commit-date: 2025-11-22
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.5

[clubby789]

IIUC the problem is that while LLVM recognizes MiMalloc::alloc as an allocator function, it is able to inline mi_malloc_aligned etc., which is not recognized. When __rust_alloc is provided by std, it is opaque enough to LLVM that the allocator attributes survive and allow it to be recognized as eliminatable.