`-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.