-
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
Ensure the scalar Reciprocal*Estimate APIs use AVX512 where possible #101800
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
2fbf67c
Ensure the scalar Reciprocal*Estimate APIs use AVX512 where possible
tannergooding eb950fe
Ensure that TensorPrimitives.Reciprocal APIs consistently use AVX512
tannergooding e954b73
Move the implementation of ReciprocalEstimate and ReciprocalSqrtEstim…
tannergooding 1bd49f0
Ensure the relevant math intrinsics are marked betterToExpand
tannergooding 1cd762a
Apply formatting patch
tannergooding 564dccf
Fixing the method header for impEstimateIntrinsic
tannergooding 61a327b
Don't use the AVX512 paths for TensorPrimitives.Reciprocal*Estimate A…
tannergooding 1810dfd
Workaround an issue where the TensorPrimitives net8 tests are not run…
tannergooding File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
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.
CC. @dotnet/jit-contrib, this did end up being a runtime issue of sorts.
There's a general assumption made by R2R that the managed implementation (for Corelib in particular) will be consistent across all paths. That was strictly not the case for the
*Estimate
APIs where they are non-deterministic across hardware by design. -- Put another way,R2R
essentially assumes thatIsa.IsSupported
is equivalent tocompOpportunisticallyDependsOn(Isa)
for corelib, but it assumes its equivalent tocompExactlyDependsOn(Isa)
for other libraries.As such, the only fix we have today is to move it into the JIT where we can explicitly use
compExactlyDependsOn(Isa)
instead and force things to be annotated correctly. This has a minor added bonus in that it improves codegen around the method slightly for more complex scenarios and makes it more consistent with the handling of other math APIs.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.
Can it be solved via ExactlyDependsOn attributes on C# side?
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.
Not from what I saw. The analyzer will actually warn in the case that you try to do something like that, because of the expectation that the paths are semantically equivalent.
It's detailed more in depth here with some explanations of what is safe vs not safe for corelib:
runtime/docs/design/coreclr/botr/vectors-and-intrinsics.md
Line 67 in 40c024f
Doing it in the JIT, which is how all the other APIs that map down to 1 instruction are handled, ended up being the simpler approach.
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.
@tannergooding so does this PR solve the non-determinism? R2R still may prejit functions with these math functions, right?
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.
No, the non-determinism is intentional for these APIs. They are explicitly
estimating
APIs that are allowed to differ in result based on the hardware they're running on. What this does fix is the non-determinism within a single process.The use of
compExactlyDependsOn
basically tells R2R that this method requiresAvx512F
and if it isn't present the functionality may differ. That will mark methods that call it as requiring themselves to be jitted.If we made these
recursive
and thereforemustExpand
, then R2R could leave a call to the method and only have the method jitted instead. But, that's a more complicated change sinceReciprocalSqrtEstimate
requires us to emit a call toSystem.Math.Sqrt
in the worst case and requires adding handling for that to platforms that don't currently have hardware intrinsic support (like Arm32).This is a relatively uncommon API (basically just used in specialized high-perf scenarios), so fixing the failing CI legs seemed more important than worrying about the handful of APIs that would be disqualified from R2R (none of which are in corelib or other core libraries,
System.Numerics.Tensors
is the only place in our own code).