-C inline-threshold has no effect with new LLVM pass manager

[MSxDOS]

The compiler produces identical binaries whatever value is set.

In this example:

const LEN: usize = 20;

pub fn test(vals1: &[usize; LEN], vals2: &[usize; LEN]) -> bool {
    test_inner(vals1) || test_inner(vals2)
}

fn test_inner(vals: &[usize; LEN]) -> bool {
    vals.iter().any(|v| v % 2 == 0)
}

test_inner is not inlined when compiled with -C opt-level=3 -C inline-threshold=9000 unless the new pass manager is manually disabled via -Z new-llvm-pass-manager=no.

https://rust.godbolt.org/z/TKGoz3h6n

Related: #61088

[MSxDOS]

cc @nikic

[nikic]

Does this flag have an any actual usage?

I don't think NewPM supports it directly, but we could map it to -Cllvm-args=-inline-threshold=.

[MSxDOS]

Not sure what you mean. This is a stable compiler flag and it's documented, so it should either work as intended or be removed.

-Cllvm-args=-inline-threshold is not the same though. They produce different binaries with same values passed to them, e.g. with old pass manager and -C opt-level=3, -C inline-threshold=275 produces the same binary as with no flag, matching the docs, but -Cllvm-args=-inline-threshold doesn't.

On a side note, I noticed the new pass manager doing weird things when it comes to function inlining in general in some occasions:

• It doesn't inline medium sized functions that are called once.
• It doesn't inline very small private functions from external crates if their public caller is marked #[inline] but does when it's not. The caller itself is also small and always gets inlined.
• A medium sized function that's called in two places gets inlined in one but not in another, while the old pass manager inlines both.

This is when compiled with 1 codegen unit and any LTO. I wonder if it's related to this issue.

[nikic]

Not sure what you mean. This is a stable compiler flag and it's documented, so it should either work as intended or be removed.

Yes, my question is whether this flag should be removed (read: deprecated and ignored). This seems like rather dubious functionality to expose under a first-class -C flag, and I think we're better off making people use -Cllvm-args if they actually know what they're doing. LLVM doesn't have a single inlining threshold, it has something like 5 different ones that apply depending on the specific case, plus another 15 or so other parameters controlling inlining behavior.

-Cllvm-args=-inline-threshold is not the same though. They produce different binaries with same values passed to them, e.g. with old pass manager and -C opt-level=3, -C inline-threshold=275 produces the same binary as with no flag, matching the docs, but -Cllvm-args=-inline-threshold doesn't.

Probably the closer analogue to the old -C inline-threshold interpretation would be -Cllvm-args=-inlinedefault-threshold=, though it's arguable whether that is really the behavior users expect for this flag.

On a side note, I noticed the new pass manager doing weird things when it comes to function inlining in general in some occasions:

• It doesn't inline medium sized functions that are called once.
• It doesn't inline very small private functions from external crates if their public caller is marked #[inline] but does when it's not. The caller itself is also small and always gets inlined.
• A medium sized function that's called in two places gets inlined in one but not in another, while the old pass manager inlines both.

This is when compiled with 1 codegen unit and any LTO. I wonder if it's related to this issue.

I'd suggest filing a separate issue for that, with examples. I don't think this is really related to -C inline-threshold.

[workingjubilee]

I don't think a backend-invariant form of reasoning about this compiler flag is possible, least of all with the somewhat arbitrary numeric API offered here, so I suspect if asked, other BE maintainers will be in favor of deprecation, but I am not sure. To that end:
cc @bjorn3 @antoyo

[antoyo]

I'm not sure there's an equivalent for this flag in gcc. There's -finline-limit, but it seems to do something different.
Thus, unless I'm wrong, it might make sense to deprecate this flag.

[hudson-ayers]

For gcc, several --param options could probably be combined to approximate this (e.g. inline-min-speedup, inline-unit-growth inline-heuristics-hint-percent, several others), but I agree there is no direct pass-through equivalent.

That said, this option going from working to doing nothing is user unfriendly -- at the very least, we should be printing a warning that users with a need to tune inlining should investigate LLVM specific flags.

My team noticed a binary size increase of > 3% just from updating Rust, which was caused because this flag silently stopped doing anything. At first, we assumed that Rust had just gotten worse, and decided not to update to a newer nightly until the regression was fixed (we work in the embedded space, where a 3% increase exhausted our available ROM). After awhile it became clear it was not getting better, so I dug deeper and found this. Using -Cllvm-args=-inline-threshold as an approximation of the old behavior got nearly all of the size back.

[insilications]

The NewPM needs more love.

[workingjubilee]

The cited issues regarding binary weight or speed are important, but this only ever controlled a purely advisory instruction, unfortunately, so in a sense these results are "not broken". LLVM always was deciding to multiply the advisory impact of this on its own inlining heuristics by some value, possibly 1, and now LLVM has decided to multiply this directive by 0 instead.

It also seems that the future of rustc is probably one that does not have a natural translation for -Cinline-threshold at all.

The concerns regarding binary weight and speed are important, but there's no need to error on usage of this. We could start issuing a warning, yes, that it currently doesn't seem to do anything. It's not clear what a final future direction for this flag should be, but that warning, too, would be... well, purely advisory. And is probably fairly easy to implement with a bit of mucking about in compiler/rustc_session or somewhere around there.

T-lang might want to discuss this at their next convenience.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. We feel that anything other than inline(always) makes no guarantees at all, and any kind of hints like this command-line option are outside lang's purview; this is entirely a question of compiler optimization.

[CastilloDel]

This is marked as help wanted, but it doesn't seem clear what the path to solve it is. Is there already a decision on whether to add a warning or deprecate the option?

[nikic]

I think those are effectively the same thing, just a question of the precise wording for the warning. Support for the legacy pass manager has been removed recently, so -C inline-threshold is now completely non-functional, under all circumstances. The message at this point could probably be something along the lines of:

warning: -C inline-threshold is no longer supported

possibly with a

use backend-specific options such as -C llvm-args=-inline-threshold=N instead

[bjorn3]

Would it make sense to translate -Cinline-threshold= to -C llvm-args=-inline-threshold=?