[SYCL][Graph] Support for sycl_ext_oneapi_enqueue_barrier extension

[mfrancepillois]

Adds support to handle barrier enqueuing with Record&Replay API. Barriers are implemented as empty nodes enforcing the required dependencies.

Adds tests that check:

1. correctness of graph structure when barriers have been enqueued,
2. processing behavior,
3. exception throwing if barriers are used within explicit API.

Notes:

1. Barriers can only be used with Record&Replay API, since barriers rely on events to enforce dependencies.
2. The scope of a barrier is limited to the Graph in which the barrier was added. As a result, if a barrier with no explicit events to wait for is part of a graph, when the graph is executed this barrier waits for all the kernels/operations in the graph that were previously submitted. However, the barrier does not wait for kernels/operations outside the graph that might have been submitted to the same execution queue.

---

[EwanC]

Hi @intel/llvm-reviewers-runtime, could we have a review of this please

[againull]

NIT: those nodes also have barrier as a predecessor?

[mfrancepillois]

Thanks. The sentence should have been "those nodes also have B1 as a predecessor".
We fixed it.

[al42and]

Multi-queues barrier is not supported

Does it mean that q.ext_oneapi_submit_barrier({e1, e2}); is forbidden if e1 and e2 come from different queues?

Or does it forbid any mixing of the queues, including the following code?

sycl::event e = q1.ext_oneapi_submit_barrier();
q2.ext_oneapi_submit_barrier({e});

[mfrancepillois]

Multi-queues barrier is not supported

Does it mean that q.ext_oneapi_submit_barrier({e1, e2}); is forbidden if e1 and e2 come from different queues?

Or does it forbid any mixing of the queues, including the following code?

sycl::event e = q1.ext_oneapi_submit_barrier();
q2.ext_oneapi_submit_barrier({e});

The sentence was not accurate. Indeed, the implementation supports both cases you mentioned. We added tests (unitests) to verify these use cases. We also updated the PR description to better explain the limitations of our implementation.

[mfrancepillois]

@intel/llvm-gatekeepers could you please merge this PR?

[steffenlarsen]

It looks like post-commit doesn't like these \ despite them being in comments. @mfrancepillois - Could you please address this issue ASAP?

[EwanC]

I've managed to reproduce this locally, will open a fix PR

[EwanC]

Turns out it's the trailing whitespace character that triggers the warning #11493
Can see it show in godbolt too https://godbolt.org/z/veeYvs6de if you add a whitespace character to the end of a line