You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally, it should be just moved there, but doing the whole move in one
PR would be harder to review as it would require multiple internal API
changes to accept `queue_impl` by raw ptr/ref instead of
`std::shared_ptr<queue_impl>` value/ref. As such, this PR does the
following:
* Store `std::variant` of queue/graph instead of just graph as two are
mutually exclusive
* Store them by reference (through `std::reference_wrapper` as
'std::variant' can't store raw references directly) instead of
`std::shared_ptr<graph_impl>`. The reason for that is that the object
`handler` is submitted to is guaranteed to be alive for the whole
lifetime of the `handler` and we don't need to extend the lifetime of
queue/graph. Corresponding changes for `handler::MQueue` have been
implemented recently already (although via
`std::shared_ptr<queue_impl> &` and not raw reference) but are
limited to prevew-only. Do the same for graphs here, essentially.
* Update all uses of the old `handler_impl::MGraph` data member as it
needs to go through new getters accessing the `std::variant` described
above.
* Update some of the direct usages of `handler::MQueue` that don't
require APIs refactoring elsewhere. The remaining uses are left to the
subsequent PR(s).
* We'll probably need to keep the `handler::MQueue` initialized properly
even after the move is complete and all internal SYCL RT accesses are
through `handler_impl` as some direct `handler::MQueue` accesses might
have been inlined into the users' applications (I'd be especially
worried about reductions).
0 commit comments