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

Kseniya Tikhomirova via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 12 06:37:02 PST 2025


================
@@ -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,
----------------
KseniyaTikhomirova wrote:

strongly disagree.
first, liboffload or UR usage is an **implementation** details. I don't see any case when user should have any info about it in runtime.
second, we **don't** expose the **choice** of plugin. we expose **information** of plugin in use for device. To me it is not fully correct to say that we expose "plugin", it is more like we expose language that is used for SYCL objects. 
This information is essential for support of interop scenarios which are part of SYCL 2020 spec. Users should have an information about used backend/plugin/standard/language so that they are able to interpret raw handles (get_native) correctly and so that they are able to choose the correct device/platform if they are interested in any specific backend.

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


More information about the llvm-commits mailing list