[SYCL] Align range with SYCL 2020 - #22889
Conversation
range to SYCL 2020 specs
|
This PR introduces an explicit line for range destructor (Rule of 5 or 0 is mandatory) and a missing overload for operator op, alongside multiple missing |
| #define __SYCL_GEN_OPT(op) \ | ||
| __SYCL_GEN_OPT_BASE(op) \ | ||
| friend range<Dimensions> operator op(const range<Dimensions> &lhs, \ | ||
| const size_t &rhs) { \ |
There was a problem hiding this comment.
This overload is not in SYCL 2020 latest documentation, not adding noexcept
There was a problem hiding this comment.
I believe the idea is that all operators for range class should be noexcept. So I vote for adding this specificator if we keep these operators.
could you please dig into commit history and check if there are any clues why these operators were introduced?
| return result; \ | ||
| } \ | ||
| friend range<Dimensions> operator op(const size_t &lhs, \ | ||
| const range<Dimensions> &rhs) { \ |
There was a problem hiding this comment.
This overload is not in SYCL 2020 latest documentation, not adding noexcept
There was a problem hiding this comment.
This overload is not in SYCL 2020 latest documentation, not adding noexcept. Also it is not guarded by __SYCL_DISABLE_ID_TO_INT_CONV__ like the previous ones
There was a problem hiding this comment.
I guess that's why you've also skipped some operators on lines 112 & 120 (upd. oh sorry you've already mentioned this above)? I'm not sure why we need these, I need to check the spec.
There was a problem hiding this comment.
I believe this should also have noexcept. It's an #else branch of #ifndef __SYCL_DISABLE_ID_TO_INT_CONV__, although I don't know yet why we need this.
Anyways, std::is_integral_v<size_t> equals to true.
UPD looks like previously in SYCL 2020 were only operators with size_t args, but DPC++ supported all integer types. Seems like then it became part of the standard, see #4538 (comment)
There was a problem hiding this comment.
@KseniyaTikhomirova do you know what is the purpose of __SYCL_DISABLE_ID_TO_INT_CONV__? At least here it looks like it does nothing as the code in both branches of this macro is same.
There was a problem hiding this comment.
function body is same but function signature is different. Depending on this macro id<> to size_t convertion is enabled and operator can accept more types. Although I don't really know the reason why it is worth disabling and it is not a default option, I assume it may be done to enable some compiler optimization. @sergey-semenov do you know anything about it?
There was a problem hiding this comment.
@sergey-semenov should we just get rid of this and unify the code?
There was a problem hiding this comment.
As it stands, this is an undocumented feature that we support, but at least we provide a way to turn it off. I think this should be formalized as a proper extension (assuming we want to keep supporting this) and then we can get rid of the macro.
There was a problem hiding this comment.
@sergey-semenov why is it not a part of spec?
https://github.com/intel/llvm/blob/sycl/sycl/include/sycl/id.hpp#L106
class id declaration in SYCl2020 contains:
// only available if Dimensions == 1
operator std::size_t() const noexcept;
There was a problem hiding this comment.
Whoops, I somehow overlooked that. Then yeah, we should just get rid of the macro.
There was a problem hiding this comment.
@Robertkq feel free to remove this or just skip this so we'll remove this later.
| range(size_t, size_t, size_t)->range<3>; | ||
| range(size_t) -> range<1>; | ||
| range(size_t, size_t) -> range<2>; | ||
| range(size_t, size_t, size_t) -> range<3>; |
There was a problem hiding this comment.
automatic change from my clang-format, I think it adheres to coding style rules of the repository
There was a problem hiding this comment.
That's ok, let's update this. In general try to use git clang-format HEAD~ after you've created a commit. It'll only format your changes then.
There was a problem hiding this comment.
Yeah this is my first time running into this kind of issue, maybe I don't know exactly how to fix it but I ran: python3 clang/tools/clang-format/git-clang-format HEAD~ which also with use of AI, I think should format correctly, but it left the files unmodified. Can you please tell me if with your clang-format version it really doesnt do this change?
I have this:
clang-format version 22.1.8 (Fedora 22.1.8-4.fc44)
Anyways, I can always just save without formatting and remove this, but I'd like to confirm / learn something new from this if possible :D
There was a problem hiding this comment.
See https://github.com/intel/llvm/blob/sycl/clang/tools/clang-format/git-clang-format
You need to put it to your PATH. Then call git clang-format *commit* where *commit* is the commit to compare current changes with, in general it's the previous commit.
There was a problem hiding this comment.
CI uses clang-format-20 Ubuntu package.
From the log:
Setting up clang-format-20 (1:20.1.8~++20250804090239+87f0227cb601-1
exp120250804210352.139) ...
There was a problem hiding this comment.
please just revert this code change
|
@KornevNikita @KseniyaTikhomirova can you take a look over the PR? Thanks! |
|
Also, I wasn't able to find an existing test file to add a case for the new overload. If it exists and it can be provided to me, I'll happily add tests, otherwise I think the PR can continue? |
could you please add this to the description |
|
|
||
| range(const range<Dimensions> &rhs) = default; | ||
| range(range<Dimensions> &&rhs) = default; | ||
| range(range<Dimensions> &&rhs) noexcept = default; |
There was a problem hiding this comment.
IIUC SYCL 2020 doesn't require these functions (for by-value semantics) to be noexcept.
There was a problem hiding this comment.
That's right.. I thought that I should apply good practice here to add noexcept for move functions so they could benefit from moves. standard library usually moves types only if they have noexcept move constructor / operator, but now I properly understand that this type is designed to be passed by value and as such this noexcept should bring little to no improvement, so I will most likely remove it from here
There was a problem hiding this comment.
I guess that's why you've also skipped some operators on lines 112 & 120 (upd. oh sorry you've already mentioned this above)? I'm not sure why we need these, I need to check the spec.
| range(size_t, size_t, size_t)->range<3>; | ||
| range(size_t) -> range<1>; | ||
| range(size_t, size_t) -> range<2>; | ||
| range(size_t, size_t, size_t) -> range<3>; |
There was a problem hiding this comment.
That's ok, let's update this. In general try to use git clang-format HEAD~ after you've created a commit. It'll only format your changes then.
e267437 to
c7f8336
Compare
|
@KornevNikita Hello, sorry for the delay. I was not able to figure out the Anyways -- please take a look over the PR. I removed the |
There was a problem hiding this comment.
can you please confirm if that should be removed or not? Thanks!
According to Sergey's comment above we can remove the #else branch of the __SYCL_DISABLE_ID_TO_INT_CONV__ macro and keep the code under the macro as default.
UPD. probably let's not do it for now, I need to investigate a bit.
| @@ -68,10 +69,12 @@ template <int Dimensions = 1> class range : public detail::array<Dimensions> { | |||
| range<Dimensions> &operator=(range<Dimensions> &&rhs) = default; | |||
| range() = default; | |||
There was a problem hiding this comment.
| range() = default; | |
| range() noexcept = default; |
c7f8336 to
7c8569f
Compare
|
@KornevNikita Is there any chance you can checkout my branch and apply the necessary formatting chances and push a commit? I can't get it to work at all.. Also, on a sidenote, is there a certain reason why CI would use clang-format version 20.x.x? It's quite a bit old and I'm pretty sure we compile clang-format or could compile format from LLVM? Anyways -- would really appreciate if you or anyone else with some free time could apply the formatting changes to me and push to this branch, thanks! |
Done. Actually you can just check the workflow output and apply it manually. it's the commit in your branch before your first commit.
IIUC https://github.com/aminya/setup-cpp is used to install clang-format. I see that https://github.com/llvm/llvm-project/blob/main/.github/workflows/pr-code-format.yml is different, likely we don't sync our workflow with llvm-project, I'll check that. |
|
@KornevNikita Thank you for the commit with format-clang changes, I will keep trying to solve the issue on my side as well. Can I get workflow approval and reviews on the PR, I believe it is close if not in merge-able state. Also, related to Thanks! |
|
Basic/alloc_pinned_host_memory.cpp: Basic/fill_accessor.cpp: Worth nothing, issues are opened for If it's suspected that it's not sporadic, can I get a re-run of the jobs? I don't have such hardware or setup to run myself |
KornevNikita
left a comment
There was a problem hiding this comment.
LGTM. @KseniyaTikhomirova could you please take a look? thanks.
range to SYCL 2020 specsrange with SYCL 2020
| } | ||
|
|
||
| size_t get(int dimension) const { | ||
| size_t get(int dimension) const noexcept { |
There was a problem hiding this comment.
check_dimension throws exception https://github.com/Robertkq/llvm/blob/fce97a96106612800cf50c2d50db736ab964d259/sycl/include/sycl/detail/array.hpp#L111
that means that it is incorrect just to mark functions calling it as noexcept with the current impl of check_dimension.
| return result; \ | ||
| } | ||
| #else | ||
| // RFC: remove these as well? |
There was a problem hiding this comment.
looks like comment which should be removed
fixes #22736
This PR introduces an explicit line for range destructor (Rule of 5 or 0 is mandatory) and a missing overload for operator op, alongside multiple missing noexcept keywords for functions