-
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
ARM64-SVE: Add TrigonometricSelectCoefficient
, TrigonometricStartingValue
#104681
Conversation
Note regarding the
|
1 similar comment
Note regarding the
|
Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics |
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.
Added some questions around test.
return result; | ||
} | ||
|
||
public static float TrigonometricStartingValue(float op1, uint op2) |
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.
are we sure we are taking into account all the possibilities of the operation? https://docsmirror.github.io/A64/2023-06/shared_pseudocode.html#impl-shared.FPMul.3? @SwapnilGaikwad, can we double check this one?
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.
The logic in the helper function is correct for the valid input (-π/4 < x <= π/4). However, behaviour of the instruction may be undefined if the input falls outside the valid range.
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.
@amanasifkhalid - for our testing purpose, we would certainly fall out of valid range. how does the API behave for them? wondering if test is robust enough to not fail for invalid values or we at least handle them?
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've verified we are generating out-of-range values, though the tests are still passing. I can constrain the inputs to this test to ensure we don't go out of range to avoid potential undefined behavior.
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've verified we are generating out-of-range values, though the tests are still passing.
that's interesting. so undefined could be that sometime they will pass and sometime they won't.
I can constrain the inputs to this test to ensure we don't go out of range to avoid potential undefined behavior.
Or probably constaint the validation for only the lanes that had valid inputs? that way we will still have coverage for invalid values, which realistically someone can pass in?
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.
Or probably constaint the validation for only the lanes that had valid inputs? that way we will still have coverage for invalid values, which realistically someone can pass in?
That sounds like a better idea. I'll update the validation logic to do this.
I've updated the tests to skip validation for invalid inputs. Stress tests are still passing. |
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.
LGTM. Thanks!
Part of #99957. @dotnet/arm64-contrib PTAL, thanks!
Test output: