Apply RemoveNoopLandingPads post-monomorphization

[Mark-Simulacrum]

On cargo this cuts ~5% of the LLVM IR lines we generate (measured with -Cno-prepopulate-passes).

[Mark-Simulacrum]

@bors2 try @rust-timer queue

[rust-bors]

⌛ Trying commit e0423d5 with merge fb9de75…

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

[rust-timer]

Finished benchmarking commit (e3a4b05): comparison URL.

Overall result: ✅ 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.4%	[0.4%, 0.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.0%	[-4.6%, -0.2%]	22
Improvements ✅ (secondary)	-2.8%	[-18.0%, -0.8%]	17
All ❌✅ (primary)	-1.9%	[-4.6%, 0.4%]	23

Max RSS (memory usage)

Results (primary -2.6%, secondary -1.3%)

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.6%	[-3.8%, -1.2%]	6
Improvements ✅ (secondary)	-1.3%	[-2.8%, -0.5%]	3
All ❌✅ (primary)	-2.6%	[-3.8%, -1.2%]	6

Cycles

Results (primary -2.4%, secondary -2.8%)

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

	mean	range	count
Regressions ❌ (primary)	1.1%	[1.1%, 1.1%]	1
Regressions ❌ (secondary)	3.2%	[0.8%, 7.1%]	4
Improvements ✅ (primary)	-2.6%	[-4.3%, -1.2%]	22
Improvements ✅ (secondary)	-5.0%	[-20.0%, -0.5%]	11
All ❌✅ (primary)	-2.4%	[-4.3%, 1.1%]	23

Binary size

Results (primary -0.6%, secondary -0.8%)

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)	-0.6%	[-1.4%, -0.0%]	66
Improvements ✅ (secondary)	-0.8%	[-3.6%, -0.0%]	30
All ❌✅ (primary)	-0.6%	[-1.4%, -0.0%]	66

Bootstrap: 461.485s -> 461.37s (-0.02%)
Artifact size: 372.20 MiB -> 371.78 MiB (-0.11%)

[cjgillot]

Is there an opportunity to reuse code from RemoveNoopLandingPads MIR pass?

[RalfJung]

Given that comments and variable names don't line up, seems better to
@bors r-

[Mark-Simulacrum]

@bors2 try @rust-timer queue

This is essentially a re-write with @cjgillot's excellent suggestion to reuse the analysis in RemoveNoopLandingPads. Also adjusted some of the naming per @RalfJung's comments -- I'm not perfectly happy with the names, some of this is sort of quasi-true (e.g., reachable is only accurate if you apply the right filters while you traverse the MIR, since we currently can't edit it in-place).

[rust-timer]

Finished benchmarking commit (d12ed3f): comparison URL.

Overall result: ✅ 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
Improvements ✅ (primary)	-2.1%	[-5.1%, -0.2%]	28
Improvements ✅ (secondary)	-3.2%	[-18.1%, -0.4%]	19
All ❌✅ (primary)	-2.1%	[-5.1%, -0.2%]	28

Max RSS (memory usage)

Results (primary -2.0%, 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)	3.4%	[2.6%, 4.2%]	2
Regressions ❌ (secondary)	2.4%	[0.7%, 4.1%]	2
Improvements ✅ (primary)	-4.2%	[-5.6%, -3.4%]	5
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.0%	[-5.6%, 4.2%]	7

Cycles

Results (primary -2.6%, secondary -4.8%)

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

	mean	range	count
Regressions ❌ (primary)	3.0%	[2.1%, 3.8%]	2
Regressions ❌ (secondary)	0.7%	[0.7%, 0.7%]	1
Improvements ✅ (primary)	-3.2%	[-5.6%, -1.5%]	18
Improvements ✅ (secondary)	-5.2%	[-19.9%, -2.0%]	14
All ❌✅ (primary)	-2.6%	[-5.6%, 3.8%]	20

Binary size

Results (primary -0.7%, secondary -1.1%)

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)	-0.7%	[-1.4%, -0.0%]	67
Improvements ✅ (secondary)	-1.1%	[-3.7%, -0.0%]	30
All ❌✅ (primary)	-0.7%	[-1.4%, -0.0%]	67

Bootstrap: 461.735s -> 459.425s (-0.50%)
Artifact size: 372.23 MiB -> 372.22 MiB (-0.00%)

[Kobzol]

Awesome wins! I wonder why it only works for debug - is it some interaction with -Zshare-generics?

[Mark-Simulacrum]

It's not clear to me. The pre-LLVM IR we emit is just as improved in either opt or debug builds, so my best guess is that LLVM's optimization passes (SimplifyCFG, if I'm reading the code right?) are able to clean up the IR we generate quickly enough that it doesn't make an impact, and I guess in debug mode those either run later or don't run at all.

I think SimplifyCFG doesn't run at all in debug:

$ rustc +nightly t.rs -Zautodiff=PrintPasses
function(ee-instrument<>),always-inline,coro-cond(coro-early,cgscc(coro-split),coro-cleanup,globaldce),function(annotation-remarks),canonicalize-aliases,name-anon-globals

I won't copy paste the extremely big opt-level=3 pipeline, but it has simplify-cfg pretty early:

annotation2metadata,forceattrs,inferattrs,coro-early,function<eager-inv>(ee-instrument<>,lower-expect,simplifycfg<bonus-inst-threshold=1;no-forward-switch-cond;no-switch-range-to-icmp;no-switch-to-lookup;keep-loops;no-hoist-common-insts;no-hoist-loads-stores-with-cond-faulting;no-sink-common-insts;speculate-blocks;simplify-cond-branch;no-speculate-unpredictables>, ...

So my guess is in opt builds LLVM is partially able to clean this up early on and as a result we don't have much benefit from doing this there. But also no loss, so I'm inclined to keep it, it doesn't hurt based on our benchmarks and there are a few opt binary size wins (https://perf.rust-lang.org/compare.html?start=6677875279b560442a07a08d5119b4cd6b3c5593&end=d12ed3fc0cb645af2b945d13048aba82f574ee91&stat=size%3Alinked_artifact&debug=false).

[klensy]

rustc +nightly t.rs -Zautodiff=PrintPasses

Weird, why this works

    -Z                                      autodiff=val -- a list of autodiff flags to enable
        Mandatory setting:
        `=Enable`

rust/compiler/rustc_codegen_llvm/src/builder/autodiff.rs

Lines 473 to 480 in 556d20a

	// First of all, did the user try to use autodiff without using the -Zautodiff=Enable flag?
	if !diff_items.is_empty()
	&& !cgcx.opts.unstable_opts.autodiff.contains(&rustc_session::config::AutoDiff::Enable)
	{
	return Err(diag_handler.handle().emit_almost_fatal(AutoDiffWithoutEnable));
	}

[Kobzol]

It's not clear to me. The pre-LLVM IR we emit is just as improved in either opt or debug builds, so my best guess is that LLVM's optimization passes (SimplifyCFG, if I'm reading the code right?) are able to clean up the IR we generate quickly enough that it doesn't make an impact, and I guess in debug mode those either run later or don't run at all.

I think SimplifyCFG doesn't run at all in debug:

$ rustc +nightly t.rs -Zautodiff=PrintPasses
function(ee-instrument<>),always-inline,coro-cond(coro-early,cgscc(coro-split),coro-cleanup,globaldce),function(annotation-remarks),canonicalize-aliases,name-anon-globals

I won't copy paste the extremely big opt-level=3 pipeline, but it has simplify-cfg pretty early:

annotation2metadata,forceattrs,inferattrs,coro-early,function<eager-inv>(ee-instrument<>,lower-expect,simplifycfg<bonus-inst-threshold=1;no-forward-switch-cond;no-switch-range-to-icmp;no-switch-to-lookup;keep-loops;no-hoist-common-insts;no-hoist-loads-stores-with-cond-faulting;no-sink-common-insts;speculate-blocks;simplify-cond-branch;no-speculate-unpredictables>, ...

So my guess is in opt builds LLVM is partially able to clean this up early on and as a result we don't have much benefit from doing this there. But also no loss, so I'm inclined to keep it, it doesn't hurt based on our benchmarks and there are a few opt binary size wins (https://perf.rust-lang.org/compare.html?start=6677875279b560442a07a08d5119b4cd6b3c5593&end=d12ed3fc0cb645af2b945d13048aba82f574ee91&stat=size%3Alinked_artifact&debug=false).

Maybe we could try what happens if we run SimplifyCFG in debug?

[Mark-Simulacrum]

I think that could make sense but I'd see it as potentially separate -- this change feels non-invasive to me (e.g., not hurting debuginfo quality) whereas SimplifyCFG seems like it could do more than that. I'm also not sure how much we want to get into changing the LLVM pass infrastructure...