Collect SwitchInt target VariantIdxs while building MaybePlacesSwitchIntData

[ashivaram23]

• 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. This is easier after Remove support for SwitchInt edge effects in backward dataflow #143769.
• Use that Vec when handling the otherwise target instead of making a new SmallVec.

This could make MaybeInitializedPlaces/MaybeUninitializedPlaces analysis slightly more efficient, particularly after #142707.

[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?