Skip to content

Conversation

dklochkov-emb
Copy link
Contributor

@dklochkov-emb dklochkov-emb commented May 12, 2025

PR fixes tests
SYCL :: GroupAlgorithm/exclusive_scan_sycl2020.cpp
SYCL :: GroupAlgorithm/inclusive_scan_sycl2020.cpp
SYCL :: GroupAlgorithm/reduce_sycl2020.cpp

due to becoming invalid in case of binary_op is logical_or and logical_and.
Spec has Mandates for each group algorithm which tells that binary_op:
binary_op(init, *first) must return a value of type T.
etc. but logical_or and logical_and in ABI breaking mode has return type boolean

@dklochkov-emb dklochkov-emb self-assigned this May 12, 2025
@dklochkov-emb dklochkov-emb requested a review from a team as a code owner May 12, 2025 11:28
bool>
: std::is_same_v<decltype(binary_op(binary_op_t(), binary_op_t())),
binary_op_t>,
"Result type of binary_op must match scan accumulation type.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

must match scan accumulation type

What is the accumulation type? Can we use it directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand, the accumulation type is the type of input/output data type, i.e part of typename InPtr:

using binary_op_t = std::remove_cv_t<std::remove_reference_t<decltype(*first)>>;
or
typename detail::remove_pointer<OutPtr>::type>

depending on __INTEL_PREVIEW_BREAKING_CHANGES

Copy link
Contributor

@aelovikov-intel aelovikov-intel May 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use it directly? Or, in other words, the current condition of the static_assert doesn't match its message. Why are you changing the condition of the assert vs changing the accumulator type? How confident are you in your change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it isn't. You still have std::is_same_v<decltype(binary_op(binary_op_t(), binary_op_t())), bool>. Either change the assert message (and explain why that would be a valid change!) or always compare with the actual result type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original problem is based on changes of return type of sycl::logical_and/sycl::logical_or.
#17239

So, when one of these structs is passed as binary operator and -fpreview-changes flag is used, the return type is not the same as the type passed to sycl::logical_and/sycl::logical_or.
That is why original assert does not work and was updated for this case

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like you've treated symptoms instead of root causing the issue. The original assert had a very specific wording that doesn't take place anymore. Do you know why it was worded like that instead of a more loose wording that would have matched your changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aelovikov-intel I just know why assert failed: some of binary operations return bool type instead of binary_op_t. These operations are logical_or, logical_and. I was wondering if you explain me 'why it was worded like that' and what is a new string to represent the right output if assert fails

@KseniyaTikhomirova
Copy link
Contributor

@dklochkov-emb @aelovikov-intel is this PR still relevant?

@aelovikov-intel
Copy link
Contributor

@dklochkov-emb @aelovikov-intel is this PR still relevant?

The problem is relevant, but I disagree with that this PR is the proper "fix". For some reason @dklochkov-emb stopped working on it. Maybe we need to revert the original patches.

@dklochkov-emb
Copy link
Contributor Author

@dklochkov-emb @aelovikov-intel is this PR still relevant?

The problem is relevant, but I disagree with that this PR is the proper "fix". For some reason @dklochkov-emb stopped working on it. Maybe we need to revert the original patches.

The original patches changed return type of some boolean operations under preview mode. We can create a separate asserts for these operations or update existing. Is there another option?

@dklochkov-emb
Copy link
Contributor Author

@aelovikov-intel I have removed sycl::logical_or/sycl::logical_and. Spec clearly says that group algorithm should be used only with logical operators which has return type T. If we need to use these operators with group algorithms, we need to update spec first.
Confirmed this approach with Greg.

Copy link
Contributor

@aelovikov-intel aelovikov-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Title/description need to be updated. Make sure to include a link to

Spec clearly says that group algorithm should be used only with logical operators which has return type T.

I'm particularly interested how it's worded, is hard failure (static_assert) expected, or should it be SFINAE?

@dklochkov-emb dklochkov-emb changed the title [SYCL] fix asserts after logical operation changes [SYCL] remove logical_or and logical_and from group algorithm tests Oct 13, 2025
@dklochkov-emb
Copy link
Contributor Author

Title/description need to be updated. Make sure to include a link to

Spec clearly says that group algorithm should be used only with logical operators which has return type T.

I'm particularly interested how it's worded, is hard failure (static_assert) expected, or should it be SFINAE?

Example for exclusive/inclusive scan is here in spec

Mandates: binary_op(*first, *first) must return a value of type std::iterator_traits::value_type.
...

Mandates: binary_op(init, *first) must return a value of type T.

etc.
I.e. there is no info if it should be checked with static_assert or SFINAE.

@aelovikov-intel
Copy link
Contributor

I.e. there is no info if it should be checked with static_assert or SFINAE.

"mandates" means static_assert. You still need to update the description with something like

Those tests were invalid because the spec

 > quote
 
requires us to report an error when <...>. As such, drop the tests.

On top of that, I think we need to update our "negative" tests to verify that we indeed report an error when used like this.

@dklochkov-emb
Copy link
Contributor Author

@aelovikov-intel Please, could you review again?

@aelovikov-intel aelovikov-intel changed the title [SYCL] remove logical_or and logical_and from group algorithm tests [SYCL] Remove logical_or and logical_and from group algorithm tests Oct 16, 2025
cgh.parallel_for<class ExclusiveScanOverGroup>(
nd_range<1>(1, 1), [=](nd_item<1> it) {
group<1> g = it.get_group();
// expected-note@+1 {{in instantiation of function template specialization 'sycl::exclusive_scan_over_group<sycl::group<>, int, sycl::logical_and<int>>' requested here}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an option to avoid writing all those "notes", grep the tests to check how it looks like.

@@ -0,0 +1,174 @@
// RUN: %clangxx -fsycl -Xclang -verify=expected -fpreview-breaking-changes -fsyntax-only -ferror-limit=0 %s
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That file should go to sycl/test, not sycl/test-e2e. You'd also be able to simplify the test by doing device compilation only and avoiding all the queue/submit/handler/etc. Check existing negative tests there.

Comment on lines +167 to +172
TestExclusiveScanOverGroup(q);
TestJointExclusiveScan(q);
TestInclusiveScanOverGroup(q);
TestJointInclusiveScan(q);
TestReduceOverGroup(q);
TestJointReduce(q);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have 6 lines here but only 2 "expected-error"s?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants