Compute jump threading opportunities in a single pass

[cjgillot]

The current implementation of jump threading walks MIR CFG backwards from each SwitchInt terminator. This PR replaces this by a single postorder traversal of MIR. In theory, we could do a full fixpoint dataflow analysis, but this has low returns as we forbid threading through a loop header, and we do not merge TOs yet.

The second commit in this PR modifies the carried state to a lighter data structure. The current implementation uses some kind of IndexVec<ValueIndex, &[Condition]>. This is needlessly heavy, as the state rarely ever carries more than a few Conditions. The first commit replaces this state with a simpler &[Condition], and puts the corresponding ValueIndex inside Condition.

The third commit is the main change. It needs a fair amount of data structure tweaks, as each condition now needs to carry its chain of blocks with it.

Later commits are perf tweaks.

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
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

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit bdf9d85 with merge d27b44e...

[bors]

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

[rust-timer]

Finished benchmarking commit (d27b44e): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@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.5%	[0.1%, 3.1%]	54
Regressions ❌ (secondary)	1.4%	[0.2%, 6.0%]	17
Improvements ✅ (primary)	-0.4%	[-0.8%, -0.2%]	8
Improvements ✅ (secondary)	-0.4%	[-0.6%, -0.2%]	8
All ❌✅ (primary)	0.4%	[-0.8%, 3.1%]	62

Max RSS (memory usage)

Results (primary -1.9%, secondary -3.6%)

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

	mean	range	count
Regressions ❌ (primary)	5.5%	[5.5%, 5.5%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.7%	[-4.7%, -2.7%]	4
Improvements ✅ (secondary)	-3.6%	[-3.6%, -3.6%]	1
All ❌✅ (primary)	-1.9%	[-4.7%, 5.5%]	5

Cycles

Results (primary 1.6%, 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)	1.6%	[0.9%, 2.9%]	3
Regressions ❌ (secondary)	2.4%	[1.7%, 3.1%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.6%	[0.9%, 2.9%]	3

Binary size

Results (primary -0.1%, 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.2%	[0.0%, 1.7%]	24
Regressions ❌ (secondary)	0.2%	[0.0%, 0.6%]	8
Improvements ✅ (primary)	-0.3%	[-0.8%, -0.0%]	49
Improvements ✅ (secondary)	-0.6%	[-13.0%, -0.1%]	86
All ❌✅ (primary)	-0.1%	[-0.8%, 1.7%]	73

Bootstrap: 689.042s -> 688.964s (-0.01%)
Artifact size: 371.85 MiB -> 371.64 MiB (-0.06%)

[rustbot]

Some changes occurred in coverage tests.

cc @Zalathar

[lcnr]

r? wg-mir-opt

[rustbot]

Failed to set assignee to vertexclique: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[lcnr]

oh, there are people in the wg which can't actually be assigned for review 😅
r? wg-mir-opt

[oli-obk]

I can yolo-review it (check that the general design makes sense and appears to be doing what it is supposed to), but I am certain I cannot antagonistically review it in the way that we should be reviewing mir opts to make sure we don't have a misoptimization. I have tried the last two weeks but I don't think I am a good reviewer for such work

[oli-obk]

this comment is now outdated

[oli-obk]

r? mir

[dianqk]

I can yolo-review it (check that the general design makes sense and appears to be doing what it is supposed to), but I am certain I cannot antagonistically review it in the way that we should be reviewing mir opts to make sure we don't have a misoptimization. I have tried the last two weeks but I don't think I am a good reviewer for such work

FYI, never mind, to me, a person who approves a pull request is never at fault. I can see a compiler growing up, always caught between bugs and features. I always see LLVM containing some miscompiled from a decade ago.

[cjgillot]

@oli-obk i don't expect you to yolo-review it, nor to bring a specific counter example to prove it wrong. Instead, I'm very interested in questions on what isn't clear, what looks fishy or inconsistent, and where you expect traps... It's my role to add in-code comments to prove myself.