UB Check blocks MIR inlining of `Vec::deref` about rust HOT 7 OPEN

I am not sure that PR fixes this. The replacement of the NullOp would occur after inlining, so we need the function to be a good inlining candidate in the first place in order to have its UbCheck removed. Resolving that was why I wrote #121767, to remove the huge penalty from the call.

We could also special-case the check calls, they already have a special inliner attribute so what's a bit more magic 🙃

from rust.

#121662 seems highly relevant, in that it introduced the monomorphization time branch IIUC

from rust.

#122975 may help, can you try again once that lands?

from rust.

That does look likely to be relevant, at least to the open-coded version; that the version using <Vec<_> as Deref>::deref isn't inlining likely means that it still won't and thus won't be able to see UbChecks transition from unknown to constant via inlining.

On the other hand, it somewhat feels like assert_unsafe_precondition! should be checking cfg!(ub_checks) "one level" up (e.g. from core::slice into alloc::vec) instead of "all the way" up (i.e. out of the sysroot crates); perhaps, in analogy to how overflow checks are handled, it's wanting for a per-function #[rustc_inherit_ub_checks] instead of a crate-wide configuration? (Although even then, unsafe fn should probably default to inheriting UB checks configuration.)

from rust.

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

from rust.

I tried this out with my reworked costs in #123179, but it still doesn't inline by default -- it needs the threshold to be raised to -Z inline-mir-hint-threshold=110 to get inlined with those new costs.

Seems like it's right on the edge. On nightly (2024-03-27) it took -Z inline-mir-hint-threshold=105 to inline https://rust.godbolt.org/z/7bK7n4d66, so it's only one instruction away.

from rust.

It was so close to the threshold that a touch of simplification in libcore got it inlining again for you.

PR up: #123190

from rust.