[llvm] [OFFLOAD] Add missing interop API for libomptarget migration (PR #172951)

[Piotr Balcer via llvm-commits]

================
@@ -1214,5 +1214,58 @@ Error olLaunchHostFunction_impl(ol_queue_handle_t Queue,
                                                 Queue->AsyncInfo);
 }
 
+Error olCreateInterop_impl(ol_device_handle_t Device, int32_t InteropContext, void *InteropSpec,
+                           void **Interop) {
+  auto Rc = Device->Device->createInterop(InteropContext, 
----------------
pbalcer wrote:

I'm not sure if I understand the distinction between the interop object and the standard queue. In SYCL, users can create queues (and other objects) directly from native handles (Level Zero, OpenCL etc):

https://github.com/oneapi-src/unified-runtime/blob/b0450fd5dc71ceaa6441baaf42516271991993a8/include/ur_api.h#L7267-L7277

This can, theoretically, allow for OpenMP and SYCL to share the underlying native Level Zero command list ("queue") handles.

More broadly, I'm a big proponent of using exclusively event-based synchronization to manage operation scheduling between different runtimes in the same application. For example, instead of creating a shared liboffload queue in SYCL and OpenMP, to make sure operation execution is synchronized, the application can pass native event handles between SYCL and OpenMP (and whatever else uses liboffload), adding synchronization just in the exact places where it's needed. Here's the entry point in UR to retrieve a native event:
https://github.com/oneapi-src/unified-runtime/blob/b0450fd5dc71ceaa6441baaf42516271991993a8/include/ur_api.h#L7664

> I think having a more general queue object (that can be configured from the upper libraries) seems like a good thing in general.

Yeah, broadly, I agree. UR queue accepts properties: https://github.com/oneapi-src/unified-runtime/blob/b0450fd5dc71ceaa6441baaf42516271991993a8/include/ur_api.h#L7118-L7126
This makes it easy for us to add additional functionality, but without modifying existing APIs. It also allows implementations to opt-out of supporting some properties.

> If the two pieces I described seem reasonable we can work on a draft implementation following that idea and rework both libomptarget, the liboffload queue abstraction and the plugin interfaces.

Yeah, having some sort of draft implementation, even if just a sketch of the API, at least for me, would allow to better grasp the problem this PR is trying to solve.

https://github.com/llvm/llvm-project/pull/172951