Reference to ZST occupies slot in function calling convention

[chadaustin]

Please forgive if redundant - I did a search but could not find relevant discussion.

I work on embedded Rust and we use ZSTs and traits for hardware abstraction layers (HAL).

If we change call sites to accept HAL objects by reference (to support unit tests with stateful HALs), I noticed Rust will occupy an argument passing slot even though &ZST could also be zero-sized.

Notice the differences in https://gcc.godbolt.org/z/s6ocP1bds

Reproducing example here:

#![no_std]

struct MyDevice;

#[unsafe(no_mangle)]
pub fn zst_by_copy(z: MyDevice, a: usize, b: usize, c: usize) -> usize {
    a + b + c
}

#[unsafe(no_mangle)]
pub fn zst_by_reference(z: &MyDevice, a: usize, b: usize, c: usize) -> usize {
    a + b + c
}

zst_by_copy:
        add     a0, a0, a1
        add     a0, a0, a2
        ret

zst_by_reference:
        add     a0, a2, a1
        add     a0, a0, a3
        ret

Is there a fundamental reason or is this simply a missed optimization opportunity?

[hanna-kruppe]

Making reference-to-ZST zero-sized instead of a pointer has been discussed and rejected in the past because it’s a breaking change in several ways. See rust-lang/rfcs#2040 (comment) for example.

[chadaustin]

Thanks for the context and previous discussion. If we limited this optimization to Rust functions, leaving extern "C" and struct representations alone, I wonder whether the optimization is feasible.

[saethlin]

The optimization is only feasible under Stacked Borrows, and it is illegal under Tree Borrows, so I think it is unlikely that this optimization will exist. The use pattern is casting that &ZST to a raw pointer to a non-ZST, then using that to do reads.

[hanna-kruppe]

See also rust-lang/unsafe-code-guidelines#256 for more discussions on this usage pattern.

[chadaustin]

Happy to close as duplicate. Alas.

[erikdesjardins]

Note that LLVM will optimize out such arguments, but only for non-exported functions. For example: https://godbolt.org/z/3Mo8xbYz6. (Depending on complexity, you may need LTO to ensure this happens.)

The functions in the original Godbolt example are exported (due to no_mangle), which inhibits LLVM from changing the signature.

So depending on your use-case (do you need these arguments in the toplevel of interrupt handlers?) it may not be an issue in practice.