Improve otherwise handling in MaybeInitializedPlaces/MaybeUninitializedPlaces

[ashivaram23]

This PR adds a couple small changes to dataflow analysis intended to make the otherwise edge handling from #142707 more tidy and efficient:

• Filter discriminants involved in a SwitchInt and map their values to VariantIdx while building MaybePlacesSwitchIntData instead of in apply_effects_in_block using next_discr. Use that Vec when handling the otherwise target instead of making a new SmallVec.
• Enable otherwise edge effects in MIR type check and borrow check.

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ashivaram23]

Note: I don't imagine this will have a major perf impact unless there's an enum with a hundred variants. I also don't expect this to fix the regressions from #142707 which I believe are largely from how the generated code interacts with later passes and LLVM.

[compiler-errors]

Let's see what perf says anyways

@bors2 try @rust-timer queue

[rust-bors]

⌛ Trying commit 04c8592 with merge 8494e68…

To cancel the try build, run the command @bors2 try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 8494e68 (8494e6881d8ac4d5f15e3ed5b25fc7c1cac5a7f8, parent: bfc046a4b8d6b57db02540182466e989a9b0fb40)

[rust-timer]

Finished benchmarking commit (8494e68): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -1.6%, secondary 2.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.5%	[2.0%, 6.9%]	2
Improvements ✅ (primary)	-1.6%	[-1.6%, -1.6%]	2
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	-1.6%	[-1.6%, -1.6%]	2

Cycles

Results (secondary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.4%, 2.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 464.174s -> 463.598s (-0.12%)
Artifact size: 374.70 MiB -> 374.72 MiB (0.00%)

[ashivaram23]

Without any reported improvements at all I don't think this has much of a point 🙃 Another followup to #142707 I wanted to try was enabling otherwise handling for more than just drop elaboration, which will probably have a noticeable effect one way or the other. I guess I could just tack that onto this PR?

[ashivaram23]

Sorry for the inactivity! I went ahead and enabled the otherwise changes for MIR type check and borrow check. (The other places it would be applicable are SanityCheck and lint_tail_expr_drop_order, but surely those can't have any effect on generated code, right? I'm not familiar enough with rustc to know why doing it in type/borrow check would either, but that's what the perf runs from the last PR implied.) I also rebased onto the latest master and force pushed.

If the next perf run isn't generally positive, I'll just close this PR since the point was to try improving regressions from the last one (which was overall neutral anyway).

@rustbot ready

[dianqk]

@bors try @rust-timer queue

[rust-bors]

⌛ Trying commit ee5374b with merge 7827a96…

To cancel the try build, run the command @bors try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 7827a96 (7827a967f3aaffb7b227fe7b8e0e6751da57d4c9, parent: 6bcdcc73bd11568fd85f5a38b58e1eda054ad1cd)

[rust-timer]

Finished benchmarking commit (7827a96): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -0.9%, secondary 0.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.5%	[3.5%, 3.5%]	1
Regressions ❌ (secondary)	3.1%	[2.3%, 4.0%]	3
Improvements ✅ (primary)	-3.1%	[-3.8%, -2.5%]	2
Improvements ✅ (secondary)	-2.5%	[-2.6%, -2.3%]	2
All ❌✅ (primary)	-0.9%	[-3.8%, 3.5%]	3

Cycles

Results (primary -2.1%, secondary -5.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-5.4%	[-5.4%, -5.4%]	1
All ❌✅ (primary)	-2.1%	[-2.1%, -2.1%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 465.172s -> 465.292s (0.03%)
Artifact size: 377.40 MiB -> 377.40 MiB (0.00%)

[ashivaram23]

No effect so I'll close.