-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Adding Int128 and UInt128 with a base software implementation #69204
Adding Int128 and UInt128 with a base software implementation #69204
Conversation
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
Tagging subscribers to this area: @dotnet/area-system-numerics Issue DetailsThis does not cover acceleration in the JIT, that will be a separate work item and will be handled in a follow up PR.
|
|
||
if ((strcmp(name, g_Int128Name) == 0) || (strcmp(name, g_UInt128Name) == 0)) | ||
{ | ||
pLayout->m_ManagedLargestAlignmentRequirementOfAllMembers = 16; // sizeof(__int128) |
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.
This needs equivalent fix in crossgen/NativeAOT and in Mono
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.
@fanyang-mono could you point me to where Mono
handles custom struct packing/alignment?
I tried checking for where that's handled for the vector types, but couldn't find it.
Int128
and UInt128
need to have 16-byte packing when targeting the System V
ABI (used by Unix) and the same packing/alignment as Int64
/UInt64
otherwise (such as on Windows or 32-bit platforms).
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.
-- I fixed this up for crossgen/NativeAOT already and added corresponding P/Invoke tests to ensure the data is passed correctly to/from Native.
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.
It's handled in mono_class_layout_fields () in metadata/class-init.c.
Not sure the mono gc supports 16 byte aligned objects on 32 bit platforms.
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.
This doesn't impact 32-bit platforms, only 64-bit platforms (and only 64-bit Unix at that).
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.
@vargaz, looks like its just blocked everywhere not just 32-bit platforms: https://github.com/dotnet/runtime/blob/main/src/mono/mono/metadata/class-init.c#L2058-L2065
It looks like Mono also isn't differentiating "alignment" from "packing" and so the layout of types that include the new Int128
, UInt128
, or the existing Vector64<T>
, Vector128<T>
, Vector256<T>
types will be incorrect.
This would explain why I couldn't find any logic touching Vector128<T>
and ensuring that it has the right packing (and therefore layout) even if the GC couldn't correctly align the overall allocation.
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.
Yes, it looks like this is not implemented right now in mono.
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.
I'll log an issue to ensure this is tracked (I don't see an existing issue).
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.
Logged #69399
Hmmm. Tests were all passing locally but failing in CI, going to need to investigate this more |
This should just need the NativeAOT and Mono fixups to ensure |
I also apparently forgot to implement conversions to and from |
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.
Have noted a few minor things.
But looks very good.
Looking forward to Int128
and UInt128
🎉😄.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs
Outdated
Show resolved
Hide resolved
Azure Pipelines successfully started running 1 pipeline(s). |
Both these runs failed with GC asserts. I do not think we have any issues tracking failures like this. Is it caused by the changes in this PR? |
I'll take a look but I find it doubtful that it'd be caused by this PR. It wasn't failing before and the only change since the last run was to update the native layout for
The other ( |
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.
Changes look good, thanks!
These asserts are generic signs of GC heap corruption. A bug introduced in common parts (e.g. parsing/formatting) can lead to intermittent crash like that. |
I'd speculate there may be another issue with There was a similar issue exposed by making |
It could be related to #69501 for example, which @SingleAccretion just opened and impacts structs. |
If this one is also related to |
I'm not 100% this fixes the issue as its not a reliable repro. But I did hit it in 20 runs with the |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
Can you give instructions for how to repro this? If we have a repro for it we need to look at it, it could be manifesting in other places that are way harder to diagnose. |
It was just running the |
The new Int128 PInvoke test is failing on Android in the extra platforms leg. |
Looks like it can't resolve the native library: @vargaz is there anything additional required for P/Invoke to work on Android? Does the library have or need some special name that differs from the default for example? |
The tvOS and iOS failures look unrelated, they seem to have just failed and look to be doing that in other jobs as well. |
Hmmm, it looks like most of the Most are marked "needs triage" as well. |
There are various other Given the breadth of P/Invoke tests disabled for Android, I'd be inclined to log an issue tracking Mono enabling interop here. The alternative would be to just block |
Disabling the interop test on Android should be fine. |
Logged #69531. Noting I grouped this with the other Mono P/Invoke disablement as tvOS and iOS didn't actually run the tests, they hit the more general timeout issue. |
This does not cover acceleration in the JIT, that will be a separate work item and will be handled in a follow up PR.