-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8338694: x86_64 intrinsic for tanh using libm #20657
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
Closed
Closed
Changes from 1 commit
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
0328101
8338694: x86_64 intrinsic for tanh using libm
vamsi-parasa 79766f1
Fix bug in NaN path
vamsi-parasa 4739ad4
Add stub initialization and extra tanh tests
vamsi-parasa 39350a3
update libm tanh reference test with code review suggestions
vamsi-parasa 4aa52bf
c1 and template generator fixes
vamsi-parasa d4ddc31
quad precision tanh tests
vamsi-parasa ca3314c
Update test/jdk/java/lang/Math/HyperbolicTests.java
vamsi-parasa c151123
remove tanh tests in seprate file
vamsi-parasa d249508
update copyright year and remove unused random from HyperbolicTests
vamsi-parasa e908eb4
Update HyperbolicTests.java
vamsi-parasa 7416537
Merge branch 'master' of https://git.openjdk.java.net/jdk into onetanh
vamsi-parasa 3664be1
update tanh additional tests
vamsi-parasa b438555
Merge branch 'master' of https://git.openjdk.java.net/jdk into onetanh
vamsi-parasa 1ee4c1f
add call to the additional tests
vamsi-parasa aa16389
remove -ve tests
vamsi-parasa 5da2754
fix is_intrinsic_supported to work properly
vamsi-parasa 4dc2e36
change ifdef from x86 to AMD64
vamsi-parasa 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 hidden or 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
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.
The allowable worst-case error is 2.5 ulp, although at many arguments FDLIBM has a smaller error.
For a general Math vs StrictMath test with an allowable 2.5 ulp error, without knowing how accurate FDLIBM is for that function and argument, a large error of approx. 2X the nominal error should be allowed (in case FDLIBM errors in one direction and the Math method errors in the other direction).
If the test is going to use randomness, then its jtreg tags should include
@key randomnessand it is preferable to use jdk.test.lib.RandomFactory to get and Random object since that handles printing out a key so the random sequence can be replicated if the test fails.
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.
Please see the test updated to use
@key randomnessandjdk.test.lib.RandomFactoryto get and Random object.So far the tests haven't failed with error of 2.5ulp. Would it be better to make it 5ulp? Please let me know.
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.
So far, this will be the only intrinsic implementation of tanh. Therefore, at the moment it is just checking the consistency of the intrinsic implementation with StrictMath/FDLIBM tanh. If the intrinsic has a ~1 ulp accuracy, it would be expected to often be within 2.5 ulps of FDLIBM tanh. However, as written the regression test would not necessarily pass against any allowable Math.tanh implementation, which is the usual criteria for java.lang.Math tests that aren't otherwise constrained (such as by being limited to a given subset of platforms).
If there was a correctly rounded tanh to compare against, then this style of testing would be valid.
Are there any plan to intrinsify sinh or cosh?
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 think instead of random we should generate offline additional correctly rounded fixed test points to cater to new algorithm using high precision arithmetic library and then simply extend the HyperbolicTests.java with these new fixed test points using existing ulp testing mechanism in the test.
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.
Thank you Sandhya(@sviswa7) for the suggestion! Will update the existing HyperbolicTests.java with new fixed point tests with quad precision reference values.
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.
Hi Joe (@jddarcy),
As suggested by Sandhya (@sviswa7), I added ~750 fixed point tests for tanh in
TanhTests.javausing the quad precision tanh implementation in libquadmath library from gcc.Please let me know if this looks good.
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.
@vamsi-parasa In my thoughts the best way to do this is add the additional tests points to HyperbolicTests.java itself in the testcases array of testTanh() method. We should remove all the other changes from HyperbolicTests.java. Also no need for separate TanhTests.java file.
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.
Hi Sandhya(@sviswa7), please see the updated code in
HyperbolicTests.javawhich removes the previous random based tests with the new fixed point tests. Also removed theTanhTests.java.