ARM64-SVE: Add TrigonometricSelectCoefficient, TrigonometricStartingValue#104681
ARM64-SVE: Add TrigonometricSelectCoefficient, TrigonometricStartingValue#104681kunalspathak merged 3 commits intodotnet:mainfrom
TrigonometricSelectCoefficient, TrigonometricStartingValue#104681Conversation
|
Note regarding the |
1 similar comment
|
Note regarding the |
|
Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics |
kunalspathak
left a comment
There was a problem hiding this comment.
Added some questions around test.
| return result; | ||
| } | ||
|
|
||
| public static float TrigonometricStartingValue(float op1, uint op2) |
There was a problem hiding this comment.
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.
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.
@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.
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.
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.
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. |
Part of #99957. @dotnet/arm64-contrib PTAL, thanks!
Test output: