[release/6.0] [mono] Use SROA-friendly struct type declarations #59060
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
LLVM's SROA can decompose loads and stores of aggregate type into a sequence of aggregate-element-typed loads and stores. Before this change, Mono translates .NET-level value types into LLVM IR-level structs containing nothing but `i8` elements. When a value type field has reference type, and a value of this value type is copied using a `memcpy` intrinsic or an LLVM IR load followed by a store, LLVM will emit code that loads managed references in multiple byte-sized fragments before reconstructing the original pointer using a sequence of ALU ops. This causes sgen to fail to pin the referent. This change works around this by translating value types to LLVM IR structs with pointer-sized fields. Packed value types with non-standard alignment will be translated into LLVM IR structs containing alignment-sized fields. Note that this does not completely guarantee that the code we generate will respect sgen's requirements. No specific guarantees are provided about the translation of non-atomic LLVM IR loads and stores to machine code. And we'll need some alternative means (perhaps a special `gc_copy_unaligned` runtime call or similar) to copy packed or misaligned value types that contain managed references. For stronger LLVM IR-level guarantees, we'll want to make use of unordered atomic loads and stores and unordered atomic memcpy, but that work is out of scope for this change. See: - https://github.com/dotnet/llvm-project/blob/release/11.x/llvm/lib/Transforms/Scalar/SROA.cpp#L3371-L3388 - https://github.com/dotnet/llvm-project/blob/release/11.x/llvm/lib/Transforms/Scalar/SROA.cpp#L3327-L3340
|
@marek-safar this will need your approval to be included in RC2. The original PR has already been approved, and is only waiting on the "ubuntu.1804.armarch.open" Helix pool to start processing jobs again. |
lambdageek
approved these changes
Sep 13, 2021
marek-safar
approved these changes
Sep 14, 2021
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #59007 to release/6.0
Customer Impact
Programs compiled using Mono LLVM can intermittently crash in the GC when copying value types that contain managed references. We previously generated type declarations of the form
%"type.name.here" = type { i8, i8, i8, ... }, which can cause SROA to load and store managed references using a non-atomic sequence of single-byte loads and stores.Testing
CI, with both the llvmaot and llvmfullaot lanes on x64 and arm64. Additionally hand-verified that the generated code satisfies sgen's requirements.
Risk
Minor. We only depend on the size and alignment of LLVM struct types and not their contents. The only exception to this happens when LLVM's SROA pass unrolls bulk copies.