Add TrustedRandomAccess specialization for Vec::extend()

[the8472]

This should do roughly the same as the TrustedLen specialization but result in less IR by using __iterator_get_unchecked
instead of Iterator::for_each

Conflicting specializations are manually prioritized by grouping them under yet another helper trait.

[the8472]

@rustbot label +T-libs-impl

[tmiasko]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit d3b03191639102db5aa13f0f525f1f68d11550ac with merge e808b7b361f6311b62118983e044a5f05634690d...

[bors]

☀️ Try build successful - checks-actions
Build commit: e808b7b361f6311b62118983e044a5f05634690d (e808b7b361f6311b62118983e044a5f05634690d)

[rust-timer]

Queued e808b7b361f6311b62118983e044a5f05634690d with parent d1065e6, future comparison URL.

[rust-timer]

Finished benchmarking try commit (e808b7b361f6311b62118983e044a5f05634690d): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[the8472]

@Dylan-DPC this is missing an assignee

[Dylan-DPC-zz]

r? @dtolnay

[dtolnay]

Thanks for the PR! The implementation looks good to me.

Would you be able to provide an example program where this produces better codegen after optimizations? Is there a simple thing I could measure with cargo bench or cargo run --release to see the improvement? (Or is that not the point of the PR?)

[the8472]

The goal here was compile time improvements, not runtime. Although runtime might benefit in some cases too, but I haven't looked at the assembly output for this PR. When available __iterator_get_unchecked just results in less pre-optimization IR and shallower call trees, which makes things easier on llvm. The perf run seems to agree.

I can run the alloc vec benchmarks and compare assembly output to see if there's some improvement on that front if you want.

[dtolnay]

Ah okay, makes sense! I am not familiar enough with reading the rustc performance comparisons to make a call whether this is worthwhile. WDYT @Mark-Simulacrum?

r? @Mark-Simulacrum

[Mark-Simulacrum]

Performance looks promising but I have a couple questions on the implementation (not necessarily blockers, just want to hear your thoughts).

[Mark-Simulacrum]

@bors r+ rollup=never

[bors]

📌 Commit 0202875 has been approved by Mark-Simulacrum

[bors]

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

[bors]

⌛ Testing commit 0202875 with merge 9111b8a...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 9111b8a to master...

[klensy]

Current perf run actually shows bigger regression, than in previous run https://perf.rust-lang.org/compare.html?start=9a700d2947f2d7f97a2c0dfca3117a8dcc255bdd&end=9111b8ae9793f18179a1336417618fc07a9cac85&stat=instructions%3Au

[the8472]

Those results are quite surprising, especially since the sign of the deltas changed in some cases.

But I guess we can revert this and I redo those changes together with #84255 which needs rebasing anyway and touches some of the same code paths, then they can be measured together.