Change:
## inline-threshold <del> This option lets you set the default threshold for inlining a function. It takes an unsigned integer as a value. Inlining is based on a cost model, where a higher threshold will allow more inlining. The default depends on the [opt-level](#opt-level): | opt-level | Threshold | |-----------|-----------| | 0         | N/A, only inlines always-inline functions | | 1         | N/A, only inlines always-inline functions and LLVM lifetime intrinsics | | 2         | 225 | | 3         | 275 | | s         | 75 | | z         | 25 | </del> <ins> This option is deprecated and does nothing. Consider using `-Cllvm-args=--inline-threshold=...`. </ins> ## instrument-coverage

Discussion:
The compiler produces identical binaries whatever value is set. In this example: is not inlined when compiled with unless the new pass manager is manually disabled via . Related:
cc
Does this flag have an any actual usage? I don't think NewPM supports it directly, but we could map it to .
Not sure what you mean. This is a stable compiler flag and it's , so it should either work as intended or be removed. is not the same though. They produce different binaries with same values passed to them, e.g. with old pass manager and , produces the same binary as with no flag, matching the docs, but 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 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.
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 flag, and I think we're better off making people use 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. Probably the closer analogue to the old interpretation would be , though it's arguable whether that is really the behavior users expect for this flag. I'd suggest filing a separate issue for that, with examples. I don't think this is really related to .
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
I'm not sure there's an equivalent for this flag in gcc.

There's , but it seems to do something different. Thus, unless I'm wrong, it might make sense to deprecate this flag.
For gcc, several options could probably be combined to approximate this (e.g. , , 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 as an approximation of the old behavior got nearly all of the size back.
The NewPM needs more love.
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 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 or somewhere around there. T-lang might want to discuss this at their next convenience.
We discussed this in today's meeting. We feel that anything other than 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.
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?
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 is now completely non-functional, under all circumstances. The message at this point could probably be something along the lines of: possibly with a
Would it make sense to translate to ?