Avoid lowering code under dead SwitchInt targets #121421

saethlin · 2024-02-22T00:13:31Z

The objective of this PR is to detect and eliminate code which is guarded by an if false, even if that false is a constant which is not known until monomorphization, or is intrinsics::debug_assertions().

The effect of this is that we generate no LLVM IR the standard library's unsafe preconditions, when they are compiled in a build where they should be immediately optimized out. This mono-time optimization ensures that builds which disable debug assertions do not grow a linkage requirement against core, which compiler-builtins currently needs: #121552

This revives the codegen side of #91222 as planned in #120848.

saethlin · 2024-02-22T00:13:46Z

@bors try @rust-timer queue

Avoid lowering code under dead SwitchInt targets r? `@ghost` Reviving rust-lang#91222 per rust-lang#120848

bors · 2024-02-22T00:14:57Z

⌛ Trying commit 2dcf095 with merge 3f638e0...

bors · 2024-02-22T00:29:28Z

💔 Test failed - checks-actions

saethlin · 2024-02-22T01:03:00Z

@bors try @rust-timer queue

bors · 2024-02-22T01:04:09Z

⌛ Trying commit 6b3d152 with merge b39e4ca...

Avoid lowering code under dead SwitchInt targets r? `@ghost` Reviving rust-lang#91222 per rust-lang#120848

bors · 2024-02-22T01:20:17Z

💔 Test failed - checks-actions

saethlin · 2024-02-22T03:39:42Z

@bors try @rust-timer queue

bors · 2024-02-22T03:40:52Z

⌛ Trying commit 127cb45 with merge b183b7a...

Avoid lowering code under dead SwitchInt targets r? `@ghost` Reviving rust-lang#91222 per rust-lang#120848

bors · 2024-02-22T05:08:21Z

☀️ Try build successful - checks-actions
Build commit: b183b7a (b183b7a248fcc8f8102bd2d19782bea9de6e3546)

oli-obk · 2024-03-13T03:13:39Z

@bors r+

bors · 2024-03-13T03:13:42Z

📌 Commit 81d6304 has been approved by oli-obk

It is now in the queue for this repository.

saethlin · 2024-03-13T03:21:52Z

I just checked to see if this PR optimizes out all the panic calls from a compiler-builtins build with debug assertions off and optimizations off, and it looks to me like since #121662 landed, it does not. It isn't entirely clear to me how to fix this. I'll put up a PR in a bit with some suggestions, but I do not like them.

bors · 2024-03-13T05:07:29Z

⌛ Testing commit 81d6304 with merge 5a6c1aa...

bors · 2024-03-13T07:16:16Z

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 5a6c1aa to master...

rust-timer · 2024-03-13T09:05:13Z

Finished benchmarking commit (5a6c1aa): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.8%	[-0.8%, -0.8%]	1
Improvements ✅ (secondary)	-0.4%	[-0.7%, -0.3%]	5
All ❌✅ (primary)	-0.8%	[-0.8%, -0.8%]	1

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Bootstrap: 674.552s -> 676.304s (0.26%)
Artifact size: 310.77 MiB -> 310.79 MiB (0.01%)

RalfJung · 2024-03-25T10:38:37Z

compiler/rustc_codegen_ssa/src/mir/mod.rs

+        if reachable_blocks.contains(bb) {
+            fx.codegen_block(bb);
+        } else {
+            // This may have references to things we didn't monomorphize, so we


This may have references to things we didn't monomorphize

How is that possible? The collector should ensure that we monomorphize everything referenced in the MIR, even in unreachable parts of the MIR.

However it could be interesting to make use of reachable_blocks_in_mono in the collector, and thus avoid collecting the functions in dead basic blocks.

🤦 I didn't fully update the comment from scottmcm's PR that I stole this from

I'm fixing this in #123272

cjgillot

Just saw a comment was never sent.

cjgillot · 2024-02-25T15:12:46Z

compiler/rustc_middle/src/mir/mod.rs

+        let mut set = BitSet::new_empty(self.basic_blocks.len());
+        self.reachable_blocks_in_mono_from(tcx, instance, &mut set, START_BLOCK);
+        set
+    }


Could you move this to traversal.rs, and refactor the computation to use the standard worklist/visited set algo?

Implemented in #123272

…try> Only collect mono items from reachable blocks Fixes the wrong commented pointed out in: rust-lang#121421 (comment) Moves the analysis to use the worklist strategy: rust-lang#121421 (comment) Also fixes rust-lang#85836, using the same reachability analysis

…jgillot Only collect mono items from reachable blocks Fixes the wrong comment pointed out in: rust-lang#121421 (comment) Moves the analysis to use the worklist strategy: rust-lang#121421 (comment) Also fixes rust-lang#85836, using the same reachability analysis

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 22, 2024

saethlin removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 22, 2024