coverage: Clean up creation of MC/DC condition bitmaps

[Zalathar]

This PR improves the code for creating and initializing MC/DC condition bitmap variables, as introduced by #123409 and modified by #124255.

• The condition bitmap variables are now created eagerly at the start of per-function codegen, via a new init_coverage method in CoverageInfoBuilderMethods. This avoids having to retroactively create the bitmaps while doing codegen for an individual coverage statement.
• As a result, we can now create and initialize those bitmaps using existing safe APIs, instead of having to perform our own unsafe call to llvm::LLVMBuildAlloca.
• This PR also tweaks the way we count the number of condition bitmaps needed, by tracking the total number of bitmaps needed (max depth + 1), instead of only tracking the maximum depth. This reduces the potential for subtle off-by-one confusion.

[rustbot]

r? @nnethercote

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

[RenjiSann]

LGTM 👍

[erikdesjardins]

I've changed the memory alignment of the u32 accesses to a hardcoded 4, instead of tcx.data_layout.i32_align.abi, because I believe that value is related to parameter-passing, not local variables.

That value is used for both local variable and parameter alignment.

However, this coverage code doesn't actually generate local variables (in the Rust sense of let x = ...), it's just a codegen implementation detail that isn't exposed to Rust code, right? So it doesn't have to obey that alignment, it can use any arbitrary alignment, as long as it's internally consistent.

I see some stores changed in this PR to match the hardcoded align 4, but I don't see any loads--where are these allocas loaded? If they're loaded by LLVM coverage intrinsics, you need to make sure that align 4 satisfies the alignment requirements of those intrinsics.

[Zalathar]

I see some stores changed in this PR to match the hardcoded align 4, but I don't see any loads--where are these allocas loaded? If they're loaded by LLVM coverage intrinsics, you need to make sure that align 4 satisfies the alignment requirements of those intrinsics.

Yeah, I'll need to look inside InstrProfiling.cpp and make sure our alignment matches how that code is interacting with the variable.

It looks like they're using Type::getInt32Ty, so I probably need to specify whatever alignment LLVM thinks that type has.

[Zalathar]

OK, it looks like the intrinsics are producing stores that don't specify an alignment, which means it defaults to the ABI alignment of the type.

So I should revert my alignment changes, and keep using the ABI alignment for i32, as before.

Thanks for the correction.

[Zalathar]

Back to using tcx.data_layout.i32_align.abi for alignment (diff).

I don't need to add an Align::FOUR constant any more, but I've kept the tests for the other alignment constants, because they're perfectly fine tests.

[nnethercote]

I don't know anything about this code, but

• You have a good PR description
• You have written nice clear comments
• @erikdesjardins obviously gave it a close look
• You have added a test
• The changes aren't that complicated

So, seems ok to me. My only suggestion is to update the PR description to remove the bit about the memory alignment. Because the PR description is used as the merge commit, so it's best for that to not contain out-of-date information. With that change made, r=me.

@bors delegate=Zalathar

[bors]

✌️ @Zalathar, you can now approve this pull request!

If @nnethercote told you to "r=me" after making some further change, please make that change, then do @bors r=@nnethercote

[Zalathar]

Good catch; I've removed the old information from the PR description.

@bors r=@nnethercote

[bors]

📌 Commit de972b7 has been approved by nnethercote

It is now in the queue for this repository.