Manually outline error on incremental_verify_ich

[Mark-Simulacrum]

This reduces codegen for rustc_query_impl by 169k lines of LLVM IR, representing
a 1.2% improvement. This code should be fairly cold, so hopefully this has minimal
performance impact.

[rust-highfive]

r? @estebank

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

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit b84ff8260574917be64786704512fdf378cf42ba with merge 47e53d2ef1e504f9558d2db16838b923943461b8...

[estebank]

r=me after perf

[bors]

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

[rust-timer]

Queued 47e53d2ef1e504f9558d2db16838b923943461b8 with parent c34ac87, future comparison URL.

[rust-timer]

Finished benchmarking commit (47e53d2ef1e504f9558d2db16838b923943461b8): comparison url.

Summary: This change led to moderate relevant regressions 😿 in compiler performance.

• Moderate regression in instruction counts (up to 1.6% on incr-unchanged builds of clap-rs)

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 try 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

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit c17a4c20ad63c8f47781c6d68ac91cac423bce42 with merge 3dc76fcad6e704ecef227c5ed3dd117b2171142d...

[bors]

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

[rust-timer]

Queued 3dc76fcad6e704ecef227c5ed3dd117b2171142d with parent e1e9319, future comparison URL.

[rust-timer]

Finished benchmarking commit (3dc76fcad6e704ecef227c5ed3dd117b2171142d): comparison url.

Summary: This change led to large relevant regressions 😿 in compiler performance.

• Large regression in instruction counts (up to 1.6% on incr-unchanged builds of clap-rs)

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 try 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

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit f48a03505d4b71aee06d9d19b88b2217445c3406 with merge 9ff05944ee09138da46fd4594ea79fba102bed35...

[bors]

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

[rust-timer]

Queued 044441c1a977a7706db0a48842282c0273b6ca67 with parent 3bfde2f, future comparison URL.

[rust-timer]

Finished benchmarking commit (044441c1a977a7706db0a48842282c0273b6ca67): 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-patched: println builds of clap-rs)
• Small regression in instruction counts (up to 0.2% on incr-unchanged builds of tuple-stress)

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 try 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

[Mark-Simulacrum]

r? @nnethercote perhaps

Regressions here seem relatively small, and in my opinion worth the improvement in bootstrap time. The impl is more complicated than I'd like, but there's not much that can be done about that - at least yet, though it may be worth exposing ArgumentV1 from std::fmt in the future - and it's fairly straightforward, just verbose. Happy to add some comments in or so if we decide to move ahead with this.

[nnethercote]

I admit I don't understand this comment. At least partly because I don't know what the referents are of "if it's not available for it".

[nnethercote]

I think you gave me a "soft" review request, so I'll give a soft approval in response :) Sounds like you're not after the actual r+ yet, but the basic change seems ok to me.

[Mark-Simulacrum]

Yeah, soft review was the intent. I clarified the comments a little which should hopefully address your question and I believe this is now ready for a full review. Didn't change any of the code so I don't think a fresh perf run is necessary.

[nnethercote]

Nice comments.

[nnethercote]

@bors r+

[bors]

📌 Commit dc65b22 has been approved by nnethercote

[bors]

⌛ Testing commit dc65b22 with merge 22c2d9d...

[bors]

☀️ Test successful - checks-actions
Approved by: nnethercote
Pushing 22c2d9d to master...

[rust-timer]

Finished benchmarking commit (22c2d9d): comparison url.

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

• Small improvement in instruction counts (up to -0.8% on incr-unchanged builds of clap-rs)
• Large regression in instruction counts (up to 1.1% on incr-unchanged builds of coercions)

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

[pnkfelix]

Visiting for weekly performance triage.

• The driving force for this change was to reduce the critical path in bootstrap time, so the most important thing to look at is the bootstrap timing data
  • (you might need to refresh the page after the data loads, I have found, in order for the browser to correctly jump to the anchored id).
• Specifically: while there is a big mix of ups and downs on the percentages column, the crate that takes the longest to compile (rustc_query_impl, the laggard at over 80 seconds of compilation time).
• This PR brings the compilation time of rustc_query_impl from 87.1 seconds down to 85.6 seconds, a -1.8% improvement.
• That is consistent with the predicted effect of the PR, and justifies the isolated impact on instruction counts.

@rustbot label: +perf-regression-triaged