Change SwitchTargets to use ScalarInt

[makai410]

Resolves: #124127

r? @ghost (let's see if the perf result is acceptable)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @vakaras

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 2c29995 (2c29995347aba3331695e95855b1df6ea0ef9fa1)
Base parent: 79ef636 (79ef636a60b0f5ca061b09122bbbca3c7b4a3b70)

[rust-timer]

Finished benchmarking commit (2c29995): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.4%	[0.1%, 0.8%]	12
Regressions ❌ (secondary)	0.6%	[0.1%, 2.7%]	42
Improvements ✅ (primary)	-0.4%	[-3.4%, -0.1%]	40
Improvements ✅ (secondary)	-0.7%	[-7.5%, -0.1%]	29
All ❌✅ (primary)	-0.2%	[-3.4%, 0.8%]	52

Max RSS (memory usage)

Results (primary 1.8%)

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

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

Cycles

Results (primary -1.6%, secondary -1.0%)

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.6%	[2.3%, 2.8%]	2
Improvements ✅ (primary)	-1.6%	[-1.8%, -1.4%]	2
Improvements ✅ (secondary)	-4.6%	[-7.3%, -1.9%]	2
All ❌✅ (primary)	-1.6%	[-1.8%, -1.4%]	2

Binary size

Results (primary 0.7%, secondary 0.5%)

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

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.0%, 3.0%]	110
Regressions ❌ (secondary)	1.6%	[0.0%, 4.4%]	63
Improvements ✅ (primary)	-0.5%	[-1.1%, -0.1%]	12
Improvements ✅ (secondary)	-0.8%	[-1.1%, -0.1%]	54
All ❌✅ (primary)	0.7%	[-1.1%, 3.0%]	122

Bootstrap: 455.642s -> 455.678s (0.01%)
Artifact size: 396.40 MiB -> 396.07 MiB (-0.08%)

[panstromek]

Terminator size changes had caused regressions before, so this is quite unfortunate, but it's also somewhat mysterious, because the effect is not always there.

I tried to reduce SwitchInt size by using slightly different representation in #159928, but it didn't have as much effect (but I also had to change other Terminator variants to make it smaller, and increase its size in metadata, so those changes could erase the wins from SwitchInt).

There's definitely a way to make SwitchInt represenation more optimal, because right now it store one len redundantly, and lot of accesses require redundant branching, but doing so requires some custom data structure and that might be an overkill.

View changes since the review

[panstromek]

Wow, these perf results are wild. What's going on here? I wonder where are the improvements coming from.

[makai410]

@panstromek This one is cursed. Instead it should be &ScalarInt::from(0_u128), otherwise the following optimization will never apply :((

Here's the llvm ir before and after the current change:
before:

; Function Attrs: nonlazybind uwtable
define noundef i16 @option_match(i32 noundef range(i32 0, 2) %x.0, i32 %x.1) unnamed_addr #0 !guid !4 {
start:
  %_0 = alloca [2 x i8], align 2
  %_2 = zext i32 %x.0 to i64
  %0 = trunc nuw i64 %_2 to i1
  br i1 %0, label %bb3, label %bb2

bb3:                                              ; preds = %start
  store i16 13, ptr %_0, align 2
  br label %bb4

bb2:                                              ; preds = %start
  store i16 42, ptr %_0, align 2
  br label %bb4

bb4:                                              ; preds = %bb3, %bb2
  %1 = load i16, ptr %_0, align 2, !noundef !5
  ret i16 %1

bb1:                                              ; No predecessors!
  unreachable
}

after:

; Function Attrs: nonlazybind uwtable
define noundef i16 @option_match(i32 noundef range(i32 0, 2) %x.0, i32 %x.1) unnamed_addr #0 !guid !4 {
start:
  %_0 = alloca [2 x i8], align 2
  %_2 = zext i32 %x.0 to i64
  switch i64 %_2, label %bb1 [
    i64 0, label %bb2
    i64 1, label %bb3
  ]

bb1:                                              ; preds = %start
  unreachable

bb2:                                              ; preds = %start
  store i16 42, ptr %_0, align 2
  br label %bb4

bb3:                                              ; preds = %start
  store i16 13, ptr %_0, align 2
  br label %bb4

bb4:                                              ; preds = %bb3, %bb2
  %0 = load i16, ptr %_0, align 2, !noundef !5
  ret i16 %0
}

View changes since the review

[makai410]

I actually don't know why skipping match simplification causes perf results like this