#[inline(never)] is not respected for trivial functions

[linkmauve]

I’m working on a pure Rust Wii/GameCube bare metal runtime, and in order to get the Dolphin emulator to output debug information to stdout I need to have a function named a certain way which gets replaced at runtime with code from outside the sandbox.

In order to do so, #[inline(never)] seemed the perfect match, but I couldn’t get it to actually force the function to never be inlined, which kind of defeats its purpose.

I found a workaround in having an empty asm!() call, which also needs to receive the registers, otherwise rustc won’t even emit the code putting the correct values for the arguments before the call. This has the downside of allocating and deallocating 16 bytes on the stack, I’m really not sure why as the assembly doesn’t actually do anything.

I tried this code:

#![feature(asm)]

#[no_mangle]
#[inline(never)]
unsafe extern "C" fn do_foo(arg: u32) {
    // Comment out this line and this function becomes a noop, and never gets
    // called.
    asm!("/* {0} */", in(reg) arg);
}

fn main() {
    unsafe { do_foo(4) };
    unsafe { do_foo(12) };
}

I expected to see this happen: codegen should be exactly the same with and without the asm!() call on line 8, due to the #[inline(never)] which requests do_foo() calls to stay as calls and not be inlined.

Instead, this happened: when line 8 is commented out, rustc detects do_foo is a noop and inlines it in main as such, which then contains a single blr instruction (equivalent of ret on x86). This renders #[inline(never)] useless.

Meta

rustc --version --verbose:

rustc 1.58.0-nightly (65f3f8b22 2021-11-21)
binary: rustc
commit-hash: 65f3f8b220f020e562c5dd848ff7319257a7ba45
commit-date: 2021-11-21
host: x86_64-unknown-linux-gnu
release: 1.58.0-nightly
LLVM version: 13.0.0

I’m building for PowerPC, but this bug also reproduces on x86.

[asquared31415]

#[inline(never)] isn't actually never, it's just an exceedingly strong hint, and this is expected behavior. This is also closer to constant folding than inlining I think, since it's seeing a constant value (nothing) being produced by a function with no side effects, and computing that value at compile time since it can't possibly have any effect as written.

As a solution to your specific problem since this presumably interacts with linking, perhaps you actually want to use an extern "C" {} block and declare the function as an import there? Not entirely sure what your use case requires. You may also be able to use #[naked] functions (though that would also require an empty asm block).

[leo60228]

I think this is true for #[inline(always)], but not #[inline(never)]. The LLVM language reference describes alwaysinline as:

This attribute indicates that the inliner should attempt to inline this function into callers whenever possible, ignoring any active inlining size threshold for this caller.

However, compare this to noinline:

This attribute indicates that the inliner should never inline this function in any situation. This attribute may not be used together with the alwaysinline attribute.

The wording is quite a bit stronger for noinline ("attempt to inline [...] whenever possible" vs. "never inline [...] in any situation").

[leo60228]

Hacky workaround:

#![feature(asm, link_llvm_intrinsics)]

extern "C" {
    #[link_name = "llvm.sideeffect"]
    pub fn sideeffect();
}

#[no_mangle]
#[inline(never)]
unsafe extern "C" fn do_foo(_arg: u32) {
    sideeffect();
}

fn main() {
    unsafe { do_foo(4) };
    unsafe { do_foo(12) };
}

(godbolt)

[nikic]

noinline controls inlining and inlining only. In this case no inlining happens -- rather, a side-effect free call is being removed. noinline does not prevent any inter-procedural optimizations apart from inlining in particular.

[linkmauve]

@leo60228, your godbolt link shows that llvm.sideeffect will elide putting the argument in r3, as can be seen when using asm!(): https://godbolt.org/z/b4K9Wxxoo

The stwu/addi instructions to grow/shrink the stack are obviously unneeded in this example (this also happens on x86), but that’s the only issue; besides asm!() not being stabilised any time soon for PowerPC.

[leo60228]

@linkmauve This is due to the DeadArgumentElimination pass. It can be effectively disabled for a function with #[linkage = "linkonce_odr"].

[Lokathor]

If this is still needed, then using the naked attribute on a function can force the function to not be inlined, but you'd have to write in the asm for getting the function to return, but if it's for a specific known platform that's probably fine.

[Enselic]

Triage: Closing with this motivation.