Stop allocating vtable entries for non-object-safe methods

[nbdd0121]

Current a vtable entry is allocated for all associated fns, even if the method is not object-safe: https://godbolt.org/z/h7vx6f35T

As a result, each vtable for Iterator' currently consumes 74 usizes. This PR stops allocating vtable entries for those methods, reducing vtable size of each Iterator vtable to 7 usizes.

Note that this PR introduces will cause more invocations of is_vtable_safe_method. So a perf run might be needed. If result isn't favorable then we might need to query-ify is_vtable_safe_method.

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit bb74667e52e83b465fb47c2d32634fdc7ace0637 with merge f884054025e1df9c3b9c6e59123af3d8014e085d...

[bors]

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

[rust-timer]

Queued f884054025e1df9c3b9c6e59123af3d8014e085d with parent 00ce166, future comparison URL.

[rust-timer]

Finished benchmarking try commit (f884054025e1df9c3b9c6e59123af3d8014e085d): comparison url.

Summary: This change led to large relevant mixed results 🤷 in compiler performance.

• Small improvement in instruction counts (up to -0.4% on full builds of inflate)
• Large regression in instruction counts (up to 2.8% on incr-unchanged builds of webrender)

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

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler 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 fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

[nbdd0121]

Introduced a query. Please do another perf run

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 6c7644deb04e51894c7abf0da8abb0fcaeaac15f with merge f4005c89228ae80fe5d43005600154074957d538...

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 83c5dab94c62142956dd2e86455afe37303ee36e with merge 4e5b7bbe1459e4b0667320310649719962750f5a...

[bors]

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

[rust-timer]

Queued 4e5b7bbe1459e4b0667320310649719962750f5a with parent 226e181, future comparison URL.

[rust-timer]

Finished benchmarking try commit (4e5b7bbe1459e4b0667320310649719962750f5a): comparison url.

Summary: This change led to small relevant mixed results 🤷 in compiler performance.

• Small improvement in instruction counts (up to -0.5% on incr-unchanged builds of encoding)
• Small regression in instruction counts (up to 0.4% on full builds of inflate)

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

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler 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 fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

[nbdd0121]

Done (I manually edited the file so I don't have to recompile everything)

[nagisa]

@bors delegate=nbdd0121

[bors]

✌️ @nbdd0121 can now approve this pull request

[nbdd0121]

Race condition :)

@bors r=nagisa

[bors]

📌 Commit 7c2031082fa92f345ec377e9f91c64da9ce51321 has been approved by nagisa

[nbdd0121]

@bors r-

[camelid]

@bors r-

CI is failing again; please wait for CI to pass before re-approving the PR (otherwise it slows down the bors queue) :)

[camelid]

Heh, another race condition :)

[nbdd0121]

@bors r=nagisa

[bors]

📌 Commit 97214ee has been approved by nagisa

[bors]

⌛ Testing commit 97214ee with merge e30b683...

[bors]

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing e30b683 to master...

[Mark-Simulacrum]

This had mixed results on landing, generally, with no significant cycle count results. Marking as triaged.