#[optimize(none)] should imply #[inline(never)]

[theemathas]

I compiled this code with -C opt-level=3:

#![feature(optimize_attribute)]

#[optimize(none)]
pub fn foo() {
    let _x = 123;
}

#[no_mangle]
pub fn bar() {
    foo();
}

I expected the assembly to either contain the number 123 somewhere, or produce a warning or error. Instead, I got this assembly:

bar:
        ret

Godbolt link

Adding #[inline(never)] to foo() gives the expected behavior. Godbolt link

Assembly after adding `#[inline(never)]`

example::foo::h70a9b33d354cf334:
        mov     dword ptr [rsp - 4], 123
        ret

bar:
        jmp     qword ptr [rip + example::foo::h70a9b33d354cf334@GOTPCREL]

The #[optimize(none)] attribute was recently added in #128657. And according to the discussion in the tracking issue at #54882, it seems like the main motivation of #[optimize(none)] is for debugging.

In this case, it seems like the compiler is inlining foo() into bar() and then proceeding to optimize bar(). This seems counterproductive for debugging. Therefore, I think that #[optimize(none)] should imply #[inline(never)]. Or if that is "too magic", then the compiler should at least produce a warning or error.

Meta

Reproduces on godbolt with rustc 1.86.0-nightly (ae5de6c75 2025-01-29)

[clubby789]

cc #128657

Looks like it's being inlined in MIR

[hanna-kruppe]

This is surprisingly subtle. On the one hand, in LLVM IR every function marked optnone must be marked noinline. So it might make sense for the MIR inliner to behave the same. On the other hand, LLVM's LangRef describes optnone like this:

This function attribute indicates that most optimization passes will skip this function, with the exception of interprocedural optimization passes.

And IPO passes can lead to inlining-equivalent effects, as discussed (for example) in #73739. So I don't know if the proposed fix is actually a reliable way to achieve "call to optimize(none) function is never eliminated" or something like that. Such calls might still get eliminated on the basis of IPO even if this specific call currently isn't eliminated with noinline. @nikic mentioned a hypothetical LLVM IR-level noipa attribute in #73739 but as far as I know this still doesn't exist.