[llvm] [SYCL] Add platform enumeration and info query using liboffload (PR #166927)

[Alexey Sachkov via llvm-commits]

================
@@ -0,0 +1,71 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+///
+/// \file
+/// This file contains the declaration of the SYCL enum class backend that is
+/// implementation-defined and is populated with a unique identifier for each
+/// SYCL backend that the SYCL implementation can support.
+///
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBSYCL___IMPL_BACKEND_HPP
+#define _LIBSYCL___IMPL_BACKEND_HPP
+
+#include <sycl/__impl/detail/config.hpp>
+
+#include <string_view>
+#include <type_traits>
+
+_LIBSYCL_BEGIN_NAMESPACE_SYCL
+
+// 4.1. Backends
+enum class backend : char {
+  opencl = 1,
+  level_zero = 2,
+  cuda = 3,
+  hip = 4,
+  all = 5,
----------------
AlexeySachkov wrote:

> It seems to me that we are only planning to support one backend at present; liboffload. Since the liboffload plugins are an implementation detail of liboffload, why would we expose the choice of plugin here?

Because from the point of view of the SYCL specification, the way how you communicate with actual low-level runtimes (i.e. `liboffload`) is an implementation detail, not the other way around. For example, [`opencl`](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#chapter:opencl-backend) backend in SYCL has its own appendix section in the SYCL 2020 specification.

> Uses OpenCL (directly, not via liboffload) as the backend.

I don't think that directly vs through a layer is important, at least not so much for most of SYCL users. Of course, quality of extra layers might be poor, but ultimately it is underlying backend which dictates what a device is capable of, not an intermediate layer.

> Again, let's say we found we needed to add support for Unified Runtime for some reason. How would that fit in. With my interpretation above, we would just add a unified_runtime enumerator (which could also support OpenCL, CUDA, HIP, L0, etc... via a plugin as an implementation detail).

I would suggest an env variable to choose between the offloading mechanisms, i.e. UR vs liboffload.

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