#inline(never) is not respected

[jrmuizel]

I tried this code:

#[inline(never)]
fn demo(s: &str) -> &str {
    s
}

pub fn main() -> &'static str {
    demo("input string")
}

it compiles to:

example::main:
        lea     rax, [rip + .L__unnamed_1]
        mov     edx, 12
        ret

.L__unnamed_1:
        .ascii  "input string"

which has demo inlined into main

This worked properly in Rust 1.11 but broke in Rust 1.12 and remains broken.

[bugadani]

godbolt.org

[bugadani]

Also, attribute is respected for public functions: godbolt.org

[nbdd0121]

I suspect this is a LLVM bug.

[jrmuizel]

Indeed. I've filed https://bugs.llvm.org/show_bug.cgi?id=46463.

[jyn514]

@rustbot modify labels: S-blocked A-codegen A-LLVM

Not sure about the codegen one.

[hanna-kruppe]

I don't think this is an LLVM bug. The inline(never) attribute controls inlining but it does not make the function opaque to other inter-procedural analyses and optimizations, which can appear to have similar effects to inlining, especially in trivial examples like this. In particular, the generated code in this example can be explained by a combination of (1) noticing that demo() returns its argument unmodified and (2) noticing demo() has no effects other than this return value.

[nagisa]

Furthermore any form of the inline attribute it is just a "hint" and is not required to be honored by the compiler.

EDIT: though I concur with @hanna-kruppe's evaluation and believe that to be the explanation as to why, regardless of what the linked LLVM issue says.

[nikic]

@hanna-kruppe is correct, this is not a bug on the LLVM side. There was some discussion that this semantic could be covered by a new noipa attribute, which is supported by GCC. (Though I haven't really heard why one would be interested in this.)

[workingjubilee]

As mentioned, this is Technically Not A Bug, and no clear motivation for guaranteeing this has been given. #[inline(never)] in practice often works... in non-trivial cases. Or just when the function is marked pub, really. If it didn't work in that case, I think there would be more work to be done, but in practice it does work in that case, so! Closing. Feel free to reopen if there was some niche case you were thinking of not adequately served by adding pub as well.

[lovely-error]

I have a case where the behavior of this attribute would be of crucial importance had it been what it claims it is. In short, I want to ease the pressure of monomorphisation an do a single implementation M which should not be exposed and then make some impls call that implementation. As you may imagine, if compiler would inline every single call to M that would defeat the purpose of the this technique.

[workingjubilee]

@lovely-error You may open a new issue explaining your use-case if you like.

But if it's just for optimization purposes, the problem is not that #[inline(never)] does not reduce inlining. It does. It's that you can't hide something in an #[inline(never)] fn monomorphic that could change the global state in a way that another instantiation couldn't see. That could provide illogical results if it is instantiated twice.