-
Notifications
You must be signed in to change notification settings - Fork 769
[NFCI][SYCL] Complete handler::MQueue
->handler_impl
move
#18767
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
Conversation
a0ac055
to
1775007
Compare
1775007
to
2c1faf5
Compare
53c9bbd
to
9591489
Compare
c578e36
to
df614b1
Compare
e19b9df
to
fd4300f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
@@ -845,11 +832,14 @@ event handler::finalize() { | |||
#endif | |||
} | |||
|
|||
// Because graph case is handled right above. | |||
assert(Queue); |
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.
Would it be better to use sycl::exception here? So, that we can catch exception even when asserts are disabled (release builds)
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.
No, exception is a recoverable error. Here we'll have a flow in the logic if that ever triggers.
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.
@aelovikov-intel hi, this PR broke sycl_cts/test_reduction:
/__w/llvm/llvm/toolchain/bin/../include/sycl/handler.hpp:3962:13: error: no matching constructor for initialization of 'handler'
3962 | handler AuxHandler(getSyclObjImpl(Queue), CGH.eventNeeded() || !InOrder);
See: https://github.com/intel/llvm/actions/runs/15549830233/job/43778612663
Could you check please?
Looking. Update: reproducible with |
As a matter of fact, I like this even more, because `type_erased_cgfo_ty` is cheap to create/pass around, we have full access to `handler_impl` in `handler.cpp` (unlike `handler.cpp` where it's opaque) and circular includes/type completeness aren't an issue anymore.
As a matter of fact, I like this even more, because `type_erased_cgfo_ty` is cheap to create/pass around, we have full access to `handler_impl` in `handler.cpp` (unlike `handler.cpp` where it's opaque) and circular includes/type completeness aren't an issue anymore.
As a matter of fact, I like this even more, because `type_erased_cgfo_ty` is cheap to create/pass around, we have full access to `handler_impl` in `handler.cpp` (unlike `handler.hpp` where it's opaque) and circular includes/type completeness aren't an issue anymore.
Issues identification/suggested fixes by @Alexandr-Konovalov.
Issues identification/suggested fixes by @Alexandr-Konovalov. This doesn't fix everything, but let's merge what we're sure about already.
Initially started in #18830
Subsequent PRs before this final one:
#18794
#18834
#18748