[panstromek]

I can't believe this passed the tests first try.

[panstromek]

@bors try @rust-timer queue

[rust-log-analyzer]

The job test-pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    Checking rustc_codegen_gcc v0.1.0 (/checkout/compiler/rustc_codegen_gcc)
error[E0308]: mismatched types
  --> compiler/rustc_codegen_gcc/src/attributes.rs:39:13
   |
39 |         let Some(ref terminator) = block.terminator else { continue };
   |             ^^^^^^^^^^^^^^^^^^^^   ---------------- this expression has type `Terminator<'tcx>`
   |             |
   |             expected `Terminator<'_>`, found `Option<_>`
   |
   = note: expected struct `Terminator<'tcx>`

[rust-bors]

☀️ Try build successful (CI)
Build commit: aa85a99 (aa85a99bc1b575ac4a2335976cbc96285ceb0f60)
Base parent: ae36fe2 (ae36fe22c7e590df40ffd53ac25fea35597c3f3d)

[rust-timer]

Finished benchmarking commit (aa85a99): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	4
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (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)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (primary -2.3%, 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)	-	-	0
Regressions ❌ (secondary)	6.5%	[4.5%, 8.5%]	2
Improvements ✅ (primary)	-2.3%	[-2.6%, -2.1%]	2
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	-2.3%	[-2.6%, -2.1%]	2

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 483.826s -> 484.513s (0.14%)
Artifact size: 406.63 MiB -> 406.69 MiB (0.01%)

[workingjubilee]

simplifies the code, so ship it I guess?

was this ever actually a None?

[panstromek]

was this ever actually a None?

Yes, it is None during MIR building and in some mir opts - most notably in SimplifyCfg. I think there's 1-2 other ones as well.

I want get rid of the Option, but this way of doing it is pretty awkward, I did it just to try it out. It replaces None with custom Terminator sentinel value (Goto: BasicBlock::MAX). This makes most of the MIR code less awkward but makes the parts that use the Option more awkward.

This might be a good awkwardness tradeoff, but it will make it more difficult to reason about and bugs surface later (when indexing into basic blocks). I'd rather refactor these places a bit to avoid the need for an option.

[workingjubilee]

Ahhh.

Yeaaaahhh.

[rust-bors]

☔ The latest upstream changes (presumably #165597) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[panstromek]

This function used to match only on Some but after using Goto MaxBB terminator as a sentinel, it will also match on that sentinel (what would be None in the old version). It's fascinating that this still works and passes all the tests. I wonder whether we accidentaly do more rounds of simpliciations because of this or similar matches in this optimization pass.

But maybe this problem is contained here because we use terminator.take which will return None even if this match matches, because it will detect the Goto Sentinel.

View changes since the review