-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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 the Vector512 and Vector512<T> types #76642
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. |
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics Issue DetailsMarking this as draft since we need to add corresponding tests to https://github.com/dotnet/runtime/tree/main/src/tests/JIT/HardwareIntrinsics/General, but it is pending #74886 to avoid conflicts.
|
src/coreclr/tools/Common/Compiler/VectorFieldLayoutAlgorithm.cs
Outdated
Show resolved
Hide resolved
The mono changes look ok. Not sure that mono can properly align this type to 64 bytes. |
Mono has a different tracking issue covering its need to properly pad all of the Vector types. Noting that padding and alignment are two different things here. RyuJIT correctly "pads" these types (e.g. if you have |
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.
Looks good to me. I only skimmed the tests, but they look comprehensive, and I'm assuming you have full coverage.
Added a few clarifying comments but overall approving this.
src/coreclr/tools/Common/Compiler/VectorFieldLayoutAlgorithm.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector256.cs
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector512.cs
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector512.cs
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector512_1.cs
Show resolved
Hide resolved
@tannergooding, is this mergable now? Thanks. |
@stephentoub, was asked to wait until at least end of the week by @davidwrighton so #74886 could go in first. Marked this "blocked" for now. |
Got it, thanks. |
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.
Reviewing the newest commits. Are all of the newly exposed methods unit tested already?
src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector512.cs
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector512.cs
Show resolved
Hide resolved
eca737d
to
1b0adc0
Compare
a72c71f
to
6be8dec
Compare
@fanyang-mono, I've logged #80467 and disabled the tests under |
Arm64 CI timeouts appear to be a broader issue atm, but I'd still like to get |
Feedback has been addressed and new review was given by other R2R/Crossgen owners
} else if ((fsig->params [0]->type == MONO_TYPE_GENERICINST) && (fsig->params [1]->type == MONO_TYPE_GENERICINST)) { | ||
instc0 = OP_FDIV; | ||
break; |
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 am curious, why was this and similar branch in the multiply case removed? It is disabling SIMD code generation for Vector128 div/mul ops for wasm and probably more on the other platforms too. It would help me to find out how to fix it.
@lewing is meanwhile trying to re-enable it in this draft #81201 to see if CI would complain.
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 looks like a merge mistake to me. The correct version should be #78784.
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 looks like it was a bad merge into this PR. The correct code is in 8158cb8be51 (from #78784) but then when the PR was merged an incomplete version from this PR was picked instead during the merge (67abfd0)
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.
Sorry for that. I don't remember a merge conflict coming up, so I'd guess this was automatically done on git's end.
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.
Cool, thanks for looking into that and confirming it.
@@ -339,9 +336,6 @@ emit_simd_ins_for_binary_op (MonoCompile *cfg, MonoClass *klass, MonoMethodSigna | |||
ins = emit_simd_ins (cfg, klass, OP_XBINOP_BYSCALAR, ins->dreg, args [1]->dreg); | |||
ins->inst_c0 = OP_FMUL; | |||
return ins; | |||
} else if ((fsig->params [0]->type == MONO_TYPE_GENERICINST) && (fsig->params [1]->type == MONO_TYPE_GENERICINST)) { |
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.
Same here.
This resolves #73262
This resolves #75791