Move alignment checks to codegen by saethlin · Pull Request #117473 · rust-lang/rust

saethlin · 2023-11-01T00:53:25Z

I have closed this PR because after thinking about the "where do we put the UB checks implementation" question a lot, I've come down on the side of not maintaining two implementations wins out. It's depressing that the only way to do that is to put them in a MIR transform, but that's the state of things and I don't have the resources on my own to change it.

Implementing UB checks entirely in a MIR transform is quite limiting. Since MIR transforms work on polymorphic MIR we don't know for sure what all our types are, and sometimes we just have to give up on inserting a check. For example we used to emit MIR to compute the alignment mask at runtime, because the pointee type could be generic. and we used to skip alignment checks where we weren't sure the pointee was sized. Implementing the checks in codegen frees us from those problems, because we get to deal with monomorphized types.

Initially I implemented this by stripping down the MIR pass to insert a new terminator, which codegen would lower to a check if it saw fit. That's the perf run that has no regression: #117473 (comment). Since then, I've decided that the better strategy is to do this entirely in codegen. Only touching codegen dramatically reduces the amount of code in the compiler that this needs to touch, and it means we will insert checks into functions from the standard library which get codegenned in a crate compiled with debug assertions. Previously, *misaligned_ptr would be checked, but misaligned_ptr.read() would not. With this PR, now it is. With this PR, we get checks in ptr::read. That's this perf run: #117473 (comment)

The only thing that jumps out at me about this codegen change is that between any two statements, codegen can change which backend block it is generating code for without changing the current MIR block. We already do insert blocks on the fly for panics, but in that case we don't stay in the new block.

I'm writing this with the expectation that I implement the niche checks in the same manner, because they have the same problem with polymorphic MIR, possibly worse.

I did a GitHub code search and the only users of the old opt-out which was -Zmir-enable-passes=-CheckAlignment were turning it off because of the problem with i686-pc-windows-msvc, but that shouldn't be a problem anymore because we don't emit alignment checks on that target. Note that -Zmir-enable-passes=-CheckAlignment will silently stop doing anything. We never check that the passes given to -Zmir-enable-passes actually match the names of any actual passes.

If the new checks cause issues, users now have the opt-out from #123411: -Zub-checks=no.

saethlin · 2023-11-12T02:12:34Z

@bors try @rust-timer queue

bors · 2023-11-12T02:13:43Z

⌛ Trying commit 165048a with merge 8d257b9...

…=<try> Move alignment checks to codegen Implementing UB checks entirely in a MIR transform is quite limiting, we don't know for sure what all our types are so we need to make a lot of sacrifices. For example in here we used to emit MIR to compute the alignment mask at runtime, because the pointee type could be generic. Implementing the checks in codegen frees us from that requirement, because we get to deal with monomorphized types. But I don't think we can move these checks entirely into codegen, because inserting the check needs to insert a new terminator into a basic block, which splits the previous basic block into two. We can't add control flow like this in codegen, but we can in MIR. So now the MIR transform just inserts a `TerminatorKind::UbCheck` which is effectively a `Goto` that also reads an `Operand` (because it either goes to the target block or terminates), and codegen expands that new terminator into the actual check. --- Also I'm writing this with the expectation that I implement the niche checks in the same manner, because they have the same problem with polymorphic MIR, possibly worse. r? `@ghost`

bors · 2023-11-12T03:39:34Z

☀️ Try build successful - checks-actions
Build commit: 8d257b9 (8d257b961e0625aa5abc7146a6ee857f6182c524)

rust-timer · 2023-11-12T06:35:58Z

Finished benchmarking commit (8d257b9): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

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

Max RSS (memory usage)

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)	2.4%	[0.4%, 4.4%]	2
Regressions ❌ (secondary)	1.8%	[0.7%, 4.2%]	4
Improvements ✅ (primary)	-1.7%	[-4.1%, -0.0%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.3%	[-4.1%, 4.4%]	6

Cycles

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.5%	[0.5%, 0.5%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.7%, -2.1%]	4
All ❌✅ (primary)	0.5%	[0.5%, 0.5%]	1

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.1%	[0.0%, 0.5%]	10
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.0%	[-0.1%, -0.0%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[-0.1%, 0.5%]	18

Bootstrap: 674.671s -> 673.178s (-0.22%)
Artifact size: 311.12 MiB -> 311.05 MiB (-0.02%)

rustbot · 2024-04-07T04:31:11Z

This PR changes MIR

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

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

This PR changes Stable MIR

cc @oli-obk, @celinval, @ouz-a

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

celinval · 2024-04-07T21:26:10Z

 RemainderByZero(Operand),
 ResumedAfterReturn(CoroutineKind),
 ResumedAfterPanic(CoroutineKind),
- MisalignedPointerDereference { required: Operand, found: Operand },


Can you please just mark this as deprecated for now instead or removing it? Thanks

bors · 2024-05-10T18:27:13Z

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

celinval · 2024-05-10T20:50:51Z

Has anyone considered creating MIR passes on monomorphic MIR? I see a pattern of pushing things to codegen that should really be implemented as instrumentation passes. The code generator shouldn't be creating new basic blocks.

saethlin · 2024-05-10T21:14:20Z

Has anyone considered creating MIR passes on monomorphic MIR?

Yes. Many times. Nobody is happy with the amount of cleverness in codegen.

MIR is monomorphized on-the-fly as an optimization, because otherwise we'd have to clone all MIR bodies at codegen so that we can mutate them. Or we could probably have a really complicated accessor for the MIR like MirPatch? MirPatch doesn't support most of the operations I've done in codegen, and it doesn't fold in access to the patched state.

celinval · 2024-05-10T23:59:13Z

Do you know what the overhead would be if we clone the bodies lazily, just for functions that need transformation? For example, I'm assuming these checks would only be required in functions that perform unsafe operations.

saethlin · 2024-05-11T00:14:01Z

Do you know what the overhead would be if we clone the bodies lazily, just for functions that need transformation? For example, I'm assuming these checks would only be required in functions that perform unsafe operations.

I think you have a bit of an optimistic view of the situation based on only looking at the changes in this PR. Consider also #121174. And also, if we had such a change I would like to use it to do SimplifyCfg on monomorphic MIR, to clean up the result of this traversal strategy:

rust/compiler/rustc_codegen_ssa/src/mir/mod.rs

Lines 270 to 281 in 6e1d947

let reachable_blocks = traversal::mono_reachable_as_bitset(mir, cx.tcx(), instance);
// Codegen the body of each block using reverse postorder
for(bb, _)in traversal::reverse_postorder(mir){
if reachable_blocks.contains(bb){
 fx.codegen_block(bb);
}else{
// We want to skip this block, because it's not reachable. But we still create
// the block so terminators in other blocks can reference it.
 fx.codegen_block_as_unreachable(bb);
}
}

I know from looking at the IR we produce that the mono-reachable traversal produces goto chains. Like everything else here, that optimization is possible to implement in a lazy fashion without some MIR to mutate, but it would be complicated.

saethlin · 2024-05-12T13:02:53Z

Based on what I'm seeing in #125025, maybe cloning all the MIR is not too expensive.

celinval · 2024-05-13T22:46:36Z

Based on what I'm seeing in #125025, maybe cloning all the MIR is not too expensive.

That's similar to our findings when we migrated to using StableMIR in Kani. StableMIR supports monomorphic bodies for instances.

RalfJung · 2024-05-14T05:40:00Z

FWIW, MIR also supports monomorphic bodies -- in the MIR-to-MiniRust translation, we monomorphize the entire MIR body before translating it.

celinval · 2024-05-14T17:24:30Z

FWIW, MIR also supports monomorphic bodies -- in the MIR-to-MiniRust translation, we monomorphize the entire MIR body before translating it.

Yes, that's how StableMIR is implemented too, but I believe you still need to clone the body.

oli-obk · 2024-06-28T08:05:42Z

+
+pub fn pointers_to_check<F>(
+ statement: &mir::Statement<'_>,
+ required_align_of: F,


Why is the API design here so that a large part of the logic lies with the caller? Is this expected to be used differently from different places in the future? Or was it just to avoid passing self?

oli-obk · 2024-06-28T08:46:08Z

Please add a codegen test that shows how we now also have alignment checks in generic code that didn't have them before

bors · 2024-07-20T16:32:05Z

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

saethlin · 2024-07-21T21:22:36Z

It turns out that since we're only checking that reads and writes are done to a place based on an aligned pointer, we actually don't run into the unsized pointee case anymore. Previously this pass was designed to check all derefs, not just reads and writes.

That means that some of the pass logic can be cleaned up, though it still needs a carve-out for unsized locals.

oli-obk · 2024-07-24T16:17:31Z

r? mir-opt I'm going on leave next week

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 Nov 1, 2023

saethlin added the T-opsem Relevant to the opsem team label Nov 1, 2023