Add -Zcross-crate-inline-threshold=yes

[saethlin]

@thomcc says this would be useful for

seeing if it makes a difference in some code if i do it when building the sysroot, since -Zbuild-std + lto helps more than it seems like it should

And I've changed the possible values as a reference to @Manishearth saying

LLVM's inlining heuristic is "yes".

[rustbot]

r? @davidtwco

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[davidtwco]

I think this makes sense, and it's a change to a nightly flag so I don't think it needs any team sign-off.

[davidtwco]

Are there any tests for -Zcross-crate-inline-threshold which you could add to?

[saethlin]

No, and there ought to be. I'll add that.

[nikic]

I don't really understand why this would be a useful option, but the option name/value combination doesn't make sense to me. This looks to me like it enables the cross crate inline threshold, not that it sets it to infinity. Should this be s/yes/always?

[saethlin]

I don't really understand why this would be a useful option

The point is to compare with a build where enabling LTO produces a significant perf improvement. If this flag produces a similar improvement, then it is possible to get that improvement by applying #[inline]. If this flag does not, then there is something else about LTO which is responsible.

This looks to me like it enables the cross crate inline threshold, not that it sets it to infinity

Well currently, it isn't the same as setting the threshold to infinity, because no matter what numeric value you pass, non-leaf functions will never be made cross-crate-inlinable. Cross-crate-inlining does not have a proper cost model yet because so far all my attempts to develop one have resulted in significant regressions in incremental build times.

[davidtwco]

@bors r+

[bors]

📌 Commit fcdd99e has been approved by davidtwco

It is now in the queue for this repository.