For MIRI, cfg out the swap vectorization logic from 94212

[scottmcm]

Because of #69488 the swap logic from #94212 doesn't currently work in MIRI.

Copying in smaller pieces is probably much worse for its performance anyway, so it'd probably rather just use the simple path regardless.

Part of #94371, though another PR will be needed for the CTFE aspect.

r? @oli-obk
cc @RalfJung

[RalfJung]

However, in Miri this will mean we are copying 4 times rather than 3 times. No idea if that's a problem for performance or not...

[RalfJung]

I agree this makes sense for Miri. Not sure if there is a nice way to also use this for CTFE without code duplication.

[oli-obk]

I think we should just fix the FIXME mentioned right there:

the block optimization also prevents MIR optimizations from
// understanding mem::replace, Option::take, etc. - a better overall
// solution might be to make ptr::swap_nonoverlapping into an intrinsic, which
// a backend can choose to implement using the block optimization, or not.

This will take care of miri, CTFE, spirv in one go

[oli-obk]

The "right" solution for that is probably to not use an intrinsic, but a lang item. So the default logic is swap_simple, but backends can intercept the lang item and generate an entirely different body for it

[oli-obk]

Ideally we'd have

• Wishlist: allow adding intrinsics in a way that doesn't break every backend #93145

working by now, but... that needs a bit more work.

[RalfJung]

The "right" solution for that is probably to not use an intrinsic, but a lang item. So the default logic is swap_simple, but backends can intercept the lang item and generate an entirely different body for it

Yeah, I was about to say that the logic that is currently implemented here would probably be quite annoying to replicate in a backend.

But also, Miri is currently broken by 3 independent issues, and we need to resolve this one to make progress on that. So given that, I think it would make sense to land this or something like #94411 rather soon. (In CTFE it only affects unstable features so hopefully it is a bit less pressing.)

[oli-obk]

@bors r+

Agreed, we can fix it cleaner later, the FIXME stays in place after all, this PR doesn't make the situation any worse

[bors]

📌 Commit b582bd3 has been approved by oli-obk

[RalfJung]

@bors r=oli-obk p=1

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Direct users towards using Rust target feature names in CLI #87402

[bors]

📌 Commit b582bd3 has been approved by 1

[RalfJung]

oops
@bors r=oli-obk p=1

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Direct users towards using Rust target feature names in CLI #87402

[bors]

📌 Commit b582bd3 has been approved by oli-obk

[bors]

⌛ Testing commit b582bd3 with merge 6a70556...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 6a70556 to master...

[rust-timer]

Finished benchmarking commit (6a70556): comparison url.

Summary: This benchmark run shows 4 relevant regressions 😿 to instruction counts.

• Arithmetic mean of relevant regressions: 0.8%
• Largest regression in instruction counts: 0.9% on incr-unchanged builds of externs debug

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

[Mark-Simulacrum]

Dropping the regression label -- externs is currently a little noisy (and we haven't absorbed that noisiness into our statistical estimation yet). Seems to be due to #93839, which makes me suspect this is related to PGO or inlining decisions of some kind. #94373 might help.