-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Mark the special ABI primitive types as having stable layout #120802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR marks special ABI primitive types (Vector types and Int128/UInt128) as having stable layout to improve R2R (ReadyToRun) performance. The change eliminates unnecessary JIT compilations for vector and Int128 operations when hardware capabilities support them.
- Removes the
vectorAbiIsStableparameter from VectorFieldLayoutAlgorithm constructors and always treats vector types as ABI stable - Updates Int128FieldLayoutAlgorithm to mark Int128/UInt128 types as having stable layout on all platforms including ARM
- Simplifies VectorOfTFieldLayoutAlgorithm by removing conditional ABI stability logic
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| TestTypeSystemContext.cs | Removed second parameter from VectorFieldLayoutAlgorithm constructor call |
| ReadyToRunCompilerContext.cs | Removed conditional ABI stability logic and always marks vector types as stable |
| VectorFieldLayoutAlgorithm.cs | Removed vectorAbiIsStable parameter and field, hardcoded LayoutAbiStable to true |
| Int128FieldLayoutAlgorithm.cs | Changed LayoutAbiStable from false to true for Int128/UInt128 types |
|
Are these types still blocked for interop (re #120367 (comment) )? |
Yep. We block those in the VM, it has nothing to do with ABI stability:
|
Why are these still getting compiled? |
Nothing triggers them in the S.P.Corelib R2R image, unlike We only have the R2R entry for |
|
R2RDump on S.P.Corelib reports |
Yeah, we don't use |
|
I'm going to log an issue for the These seem like cases we can actually avoid since they will always fault and shouldn't appear in code. It'd be more useful to pick the "most common" |
|
@jkotas, any other questions/comments? |
Yes, there is more fine-tunning we should do here, but it does not need to block this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
|
Logged #120816 |
This resolves #120367 and was tested using the following program:
Results
Before
After - .NET 10
AVX512 Capable Machine
AVX512=0
AVX2=0
SSE42=0
HWIntrinsics=0
After - .NET 11
AVX512 Capable Machine
AVX512=0
AVX2=0