-
Notifications
You must be signed in to change notification settings - Fork 730
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
[SYCL][DOC] Move sycl::complex's extension from proposed to experimental #9867
[SYCL][DOC] Move sycl::complex's extension from proposed to experimental #9867
Conversation
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!
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, I think I missed this extension when it was first added to "proposed". I've added some comments below. I think most of these are just comments on the spec, so they should not affect the implementation.
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.
Thanks, your previous commit did help clarify things. Since you added some new APIs, though, I have some new comments. :-)
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
…mplex-extension-to-experimental
…rimental extension
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
Hello @gmlueck @abagusetty 👋 After looking a bit more at the literal operators, there are some concerns regarding their introduction to this extension and its implementation. Implementation-wise, the literal operators can't be used in device code due to the no support of long-double. Also, user-defined operators should be prefixed by PR-wise, I'll remove all references of the literal operators from this PR, and will revert the deletation of the |
The latest changes to the "experimental" extension look good. I do not think we should simply restore the old "proposed" extension, though. When I do a "diff" between the "experimental" and "proposed" versions of the extension in this PR, there are many irrelevant differences. My preference would be to do the following:
This would allow discussion to continue on that section about literals until the issues are resolved. Once they are resolved, we can merge that second PR. |
…mplex-extension-to-experimental
Status: Waiting on revert PR for literal operators, which will then be merged into this PR and then |
…omplex" (#10521) Reverts #9819 As mentioned in the PR #9867, this introduction of literal operators creates some issues due to literal operators receiving arguments as `long double` which are not supported on device code (and only works on host side); and our worries that users will try to use it and will not understand why it does not work. Also, user-defined literal operators should be declared with a `_` prefix to not clash with the standard literal operators when `using namespace std::literals`. Reverting this PR will facilitate the merge of the previously mentioned PR and have a place where the issues from this introduction are listed. Regardless of this PR, we'd still like to have support for literal operators for complex, so if you (@abagusetty) could open up a new PR for re-introducing the literal operator if a solution can be found also to handle it in device code, that would be great! @gmlueck @abagusetty
Closing this branch for another PR, which will be created on TOP of sycl (containing the revert commit) to not add all the merge and delete commits from resolving the conflicts that happened during the lifetime of this PR. |
…o experimental (#10553) This PR proposed the modification of the sycl::complex's extension be moved from ```./proposed``` to ```./experimental```, respecting the ```sycl/doc/extensions/README```: The ```sycl::complex``` is implemented but may change in the future. Reference PR: #9867 @abagusetty @gmlueck @steffenlarsen @AerialMantis --------- Co-authored-by: Greg Lueck <gregory.m.lueck@intel.com>
…omplex" (intel#10521) Reverts intel#9819 As mentioned in the PR intel#9867, this introduction of literal operators creates some issues due to literal operators receiving arguments as `long double` which are not supported on device code (and only works on host side); and our worries that users will try to use it and will not understand why it does not work. Also, user-defined literal operators should be declared with a `_` prefix to not clash with the standard literal operators when `using namespace std::literals`. Reverting this PR will facilitate the merge of the previously mentioned PR and have a place where the issues from this introduction are listed. Regardless of this PR, we'd still like to have support for literal operators for complex, so if you (@abagusetty) could open up a new PR for re-introducing the literal operator if a solution can be found also to handle it in device code, that would be great! @gmlueck @abagusetty
…o experimental (intel#10553) This PR proposed the modification of the sycl::complex's extension be moved from ```./proposed``` to ```./experimental```, respecting the ```sycl/doc/extensions/README```: The ```sycl::complex``` is implemented but may change in the future. Reference PR: intel#9867 @abagusetty @gmlueck @steffenlarsen @AerialMantis --------- Co-authored-by: Greg Lueck <gregory.m.lueck@intel.com>
This PR proposed the modification of the sycl::complex's extension be moved from
./proposed
to./experimental
, respecting thesycl/doc/extensions/README
: Thesycl::complex
is implemented but may change in the future.