[SYCL] Add platform enumeration and info query using liboffload #166927

KseniyaTikhomirova · 2025-11-07T11:50:49Z

This is part of the SYCL support upstreaming effort. The relevant RFCs can be found here:

https://discourse.llvm.org/t/rfc-add-full-support-for-the-sycl-programming-model/74080 https://discourse.llvm.org/t/rfc-sycl-runtime-upstreaming/74479

The SYCL runtime is device-agnostic and uses liboffload for offloading to GPU. This commit adds a dependency on liboffload, implementation of platform::get_platforms, platform::get_backend and platform::get_info methods, initial implementation of sycl-ls tool for manual testing of added functionality.

Plan for next PR:

device/context impl, rest of platform
test infrastructure (depends on L0 liboffload plugin CI, our effort is joined) ABI tests

This is part of the SYCL support upstreaming effort. The relevant RFCs can be found here: https://discourse.llvm.org/t/rfc-add-full-support-for-the-sycl-programming-model/74080 https://discourse.llvm.org/t/rfc-sycl-runtime-upstreaming/74479 The SYCL runtime is device-agnostic and uses liboffload for offloading to GPU. This commit adds a dependency on liboffload, implementation of platform::get_platforms, platform::get_backend and platform::get_info methods, initial implementation of sycl-ls tool for manual testing of added functionality. Plan for next PR: device/context impl, rest of platform test infrastructure (depends on L0 liboffload plugin CI, our effort is joined) ABI tests

KseniyaTikhomirova · 2025-11-07T11:52:56Z

@tahonermann, @dvrogozh, @asudarsa, @aelovikov-intel, @sergey-semenov, @bader, @againull, @YuriPlyakhin, @vinser52

FYI, published for review.

libsycl/include/sycl/__impl/detail/obj_base.hpp

libsycl/include/sycl/__impl/exception.hpp

libsycl/include/sycl/__impl/info/platform.hpp

aelovikov-intel · 2025-11-07T17:33:02Z

libsycl/include/sycl/__impl/backend.hpp

+    typename backend_traits<Backend>::template return_type<SYCLObjectT>;
+
+namespace detail {
+inline std::string_view get_backend_name(const backend &Backend) {


I think we need to use something like _LIBCPP_HIDE_FROM_ABI here, if I understand the idea behind it correctly.

I would leave questions about ABI till the time I will add ABI tests

If I understand correctly, in intel/llvm this function is defined in headers only because we want to use it in the sycl-ls tool so the tool is always aligned on "known" backend with the SYCL RT.

If this intent still stands, I would add a comment about it, or otherwise this function should not exist here at all, because we don't use it anywhere else in the headers

it is still used in sycl-ls.
added tiny comment
b15b6c0

I recommend addressing ABI exposures as soon as possible. The code should be designed around ABI concerns if a stable ABI is to be supported. Delay could make handling ABI more complicated later.

I will remove this function form public headers

although I don't understand why inline detail fully defined in header function should have any specific ABI related handling. What case do we consider?

@KseniyaTikhomirova, the concern with inline functions is that they might not be inlined. If the inline function definition is changed such that two translation units observe different definitions and those definitions are not inlined, then the program will contain two distinct definitions, one of which will be selected by the linker or loader and used to satisfy all non-inlined references.

libsycl/include/sycl/__impl/platform.hpp

libsycl/src/CMakeLists.txt

libsycl/src/detail/global_objects.cpp

libsycl/src/detail/platform_impl.cpp

libsycl/src/detail/platform_impl.hpp

AlexeySachkov · 2025-11-17T16:48:14Z

libsycl/include/sycl/__impl/backend.hpp

+    typename backend_traits<Backend>::template return_type<SYCLObjectT>;
+
+namespace detail {
+inline std::string_view get_backend_name(const backend &Backend) {


If I understand correctly, in intel/llvm this function is defined in headers only because we want to use it in the sycl-ls tool so the tool is always aligned on "known" backend with the SYCL RT.

If this intent still stands, I would add a comment about it, or otherwise this function should not exist here at all, because we don't use it anywhere else in the headers

libsycl/src/detail/offload/offload_utils.cpp

libsycl/src/detail/offload/offload_utils.hpp

libsycl/src/detail/platform_impl.hpp

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

@brief

Various offload APIs `olGet*Info` are essentially untyped because they "return" value via `void *PropValue` output parameter. However, for C++ consumers (e.g., [SYCL][1] in llvm#166927) it would be beneficial if we could recover that type information. Before this PR it was only encoded in the comments near corresponding information info descriptors, e.g., ```c++ /////////////////////////////////////////////////////////////////////////////// /// @brief Supported event info. typedef enum ol_event_info_t { /// [ol_queue_handle_t] The handle of the queue associated with the device. OL_EVENT_INFO_QUEUE = 0, /// [bool] True if and only if the event is complete. OL_EVENT_INFO_IS_COMPLETE = 1, /// @cond OL_EVENT_INFO_LAST = 2, OL_EVENT_INFO_FORCE_UINT32 = 0x7fffffff /// @endcond } ol_event_info_t; ``` so was imposible for consumers to recover programmatically. [1] https://github.com/llvm/llvm-project/blob/b22192afdcbda7441e7a8fe7cbc9a06903e9e6ea/libsycl/src/detail/platform_impl.hpp#L78-L90

@brief

Various offload APIs `olGet*Info` are essentially untyped because they "return" value via `void *PropValue` output parameter. However, for C++ consumers (e.g., [SYCL][1] in llvm#166927) it would be beneficial if we could recover that type information. Before this PR it was only encoded in the comments near corresponding information info descriptors, e.g., ```c++ /////////////////////////////////////////////////////////////////////////////// /// @brief Supported event info. typedef enum ol_event_info_t { /// [ol_queue_handle_t] The handle of the queue associated with the device. OL_EVENT_INFO_QUEUE = 0, /// [bool] True if and only if the event is complete. OL_EVENT_INFO_IS_COMPLETE = 1, /// @cond OL_EVENT_INFO_LAST = 2, OL_EVENT_INFO_FORCE_UINT32 = 0x7fffffff /// @endcond } ol_event_info_t; ``` so was imposible for consumers to recover programmatically. [1] https://github.com/llvm/llvm-project/blob/b22192afdcbda7441e7a8fe7cbc9a06903e9e6ea/libsycl/src/detail/platform_impl.hpp#L78-L90

@brief

Various offload APIs `olGet*Info` are essentially untyped because they "return" value via `void *PropValue` output parameter. However, for C++ consumers (e.g., SYCL in llvm#166927) it would be beneficial if we could recover that type information. Before this PR it was only encoded in the comments near corresponding information info descriptors, e.g., ```c++ /////////////////////////////////////////////////////////////////////////////// /// @brief Supported event info. typedef enum ol_event_info_t { /// [ol_queue_handle_t] The handle of the queue associated with the device. OL_EVENT_INFO_QUEUE = 0, /// [bool] True if and only if the event is complete. OL_EVENT_INFO_IS_COMPLETE = 1, /// @cond OL_EVENT_INFO_LAST = 2, OL_EVENT_INFO_FORCE_UINT32 = 0x7fffffff /// @endcond } ol_event_info_t; ``` and not accessible programmatically.

libsycl/src/detail/platform_impl.hpp

libsycl/include/sycl/__impl/platform.hpp

libsycl/include/sycl/__impl/exception.hpp

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

pbalcer · 2025-11-20T14:17:24Z

libsycl/src/detail/offload/offload_utils.cpp

+_LIBSYCL_BEGIN_NAMESPACE_SYCL
+namespace detail {
+
+const char *stringifyErrorCode(int32_t error) {


I think this API should become an liboffload entry point. I'll add that to my TODO list.

There is allready API in liboffload. There are << operator for enum ol_errc_t

Check OffloadPrint.hpp (note this is tablegen generated file)

Kseniya to check if we can reuse it

update: can't reuse since we won't use llvmSupport lib for SYCl RT but operator returns llvm::raw_stream

aelovikov-intel · 2025-11-20T23:10:31Z

libsycl/include/sycl/__impl/info/platform.def

+#ifndef __SYCL_PARAM_TRAITS_SPEC
+static_assert(false, "__SYCL_PARAM_TRAITS_SPEC is required but not defined");
+#endif
+
+// 4.6.2.4. Information descriptors
+__SYCL_PARAM_TRAITS_SPEC(platform, version, std::string, OL_PLATFORM_INFO_VERSION)
+__SYCL_PARAM_TRAITS_SPEC(platform, name, std::string, OL_PLATFORM_INFO_NAME)
+__SYCL_PARAM_TRAITS_SPEC(platform, vendor, std::string, OL_PLATFORM_INFO_VENDOR_NAME)


Subjective, but I'm not a fan of this approach for two reasons:

Smart use of preprocessor in distributable header files (i.e., libsycl/include instead of libsycl/source/**).

OL_* are implementation details and don't need to be present in those distributable headers.

I think avoiding it doesn't result in too much code duplication: 823c765, but I understand that this is subjective.

Macro in exports can be avoided too, but that's probably too much magic:

// sycl.hpp #define _EXPORT __attribute__((visibility("default"))) struct S { template <typename> _EXPORT void foo(); }; // libsycl.so template <typename> [[gnu::used]] _EXPORT void S::foo() {} template _EXPORT void S::foo<char>(); // current approach // "Clever" helper, needs `[[gnu::used]]` above. template <typename... Ts> void instantiate_helper() { (((void)(&S::foo<Ts>), ...)); } static void instantiate() { instantiate_helper<int, float, double>(); }

$ clang++ a.cpp -c -fvisibility=hidden -fvisibility-inlines-hidden -O0 ; nm a.o | c++filt 0000000000000000 W void S::foo<char>() 0000000000000000 W void S::foo<double>() 0000000000000000 W void S::foo<float>() 0000000000000000 W void S::foo<int>() $ clang++ a.cpp -c -fvisibility=hidden -fvisibility-inlines-hidden -O3 ; nm a.o | c++filt 0000000000000000 W void foo<char>() 0000000000000000 W void foo<double>() 0000000000000000 W void foo<float>() 0000000000000000 W void foo<int>()

I'd like to ask other folks for opinion here. The benefit that .def file provides is necessity in update of only one place in the code to add info or property (we use the same approach there) if there is no special handling.

@sergey-semenov, @bader, @vinser52, @tahonermann, @AlexeySachkov do you have any preference?

Subjective, but I'm not a fan of this approach for two reasons:

Smart use of preprocessor in distributable header files (i.e., libsycl/include instead of libsycl/source/**).

OL_* are implementation details and don't need to be present in those distributable headers.

I don't understand the problem with using pre-processor in distributed header files, but I agree that mapping from SYCL API to liboffload API should be done in the library source code.

I am going to apply Andrey's proposal. Please let me know if anyone has objections.
the reason is:
I wanted info descriptors declaration to be independent for SYCL obj in terms of header files (the opposite to what we have in https://github.com/intel/llvm/blob/sycl/sycl/include/sycl/detail/info_desc_helpers.hpp).
With macro it means pretty low level of unification for helpers. Base class for info desc as proposed by Andrey gives opportunities to achieve the goal I wanted. Plus 3 people agreed that Offload RT codes should be hidden in SYCL RT that already weakens approach with macros.

I have started implementation of 'device' and there we will be able to check & see how it fits into our code base.

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

libsycl/src/detail/platform_impl.hpp

libsycl/include/sycl/__impl/detail/obj_base.hpp

libsycl/src/detail/global_objects.cpp

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova · 2025-12-08T18:04:17Z

I'd like to define naming style for the upstreaming code base.

Given:
General LLVM rule says:

In general, names should be in camel case (e.g. TextFileReader and isLValue())

and

As an exception, classes that mimic STL classes can have member names in STL’s style of lowercase words separated by underscores (e.g. begin(), push_back(), and empty()).

SYCL 2020 declare types in STL's style with snake case.

LLVM guide has no requirements about file names so I suggest:

all file names under libsycl folder (.h, .cpp, .md, etc) will be in snake_case (no exceptions)
SYCL API type names - follow SYCL2020 spec naming - snake_case
all detail (excluding STL-like types) types to use CamelCase.

changes comparing to impl/llvm:
all API and impl related files are already in snake case but docs and tests use mixed style.
I suggest to use snake_case for all files in repo.

docs example:
https://github.com/intel/llvm/blob/sycl/sycl/doc/design/CompileTimeProperties.md
mixed style examples (see folder names as well)
https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/AddressCast/dynamic_address_cast.cpp
https://github.com/intel/llvm/blob/sycl/sycl/unittests/accessor/AccessorImplicitConversion.cpp
https://github.com/intel/llvm/blob/sycl/sycl/test/e2e_test_requirements/check_e2eexpr_logic.cpp

Apply CamelCase to our impl and service classes in snake_case, for example platform_impl should become PlatformImpl and so on:
example, see forward decl: https://github.com/intel/llvm/blob/sycl/sycl/source/detail/program_manager/program_manager.hpp#L76

@bader @tahonermann could you please provide your opinion:

should we even align style or it is good to go with what we have in intel/llvm
agree or not with proposed strategy

bader · 2025-12-08T21:50:56Z

I'd like to define naming style for the upstreaming code base.

LLVM guide has no requirements about file names so I suggest:

all file names under libsycl folder (.h, .cpp, .md, etc) will be in snake_case (no exceptions)

SYCL API type names - follow SYCL2020 spec naming - snake_case

all detail (excluding STL-like types) types to use CamelCase.

@KseniyaTikhomirova, please, create a libsycl/docs/CodingGuidelines.rst file and put your suggestion there. Let's separate this discussion from adding SYCL platform.

changes comparing to impl/llvm:

What is impl/llvm? Do you mean intel/llvm repository?

tahonermann

I got part of the way through the PR today. I'll review more tomorrow.

libsycl/CMakeLists.txt

libsycl/docs/index.rst

libsycl/include/sycl/__impl/backend.hpp

libsycl/include/sycl/__impl/detail/macro_definitions.hpp

libsycl/include/sycl/__impl/detail/obj_utils.hpp

libsycl/include/sycl/__impl/exception.hpp

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova · 2025-12-11T16:51:52Z

I'd like to define naming style for the upstreaming code base.
LLVM guide has no requirements about file names so I suggest:

all file names under libsycl folder (.h, .cpp, .md, etc) will be in snake_case (no exceptions)

SYCL API type names - follow SYCL2020 spec naming - snake_case

all detail (excluding STL-like types) types to use CamelCase.

@KseniyaTikhomirova, please, create a libsycl/docs/CodingGuidelines.rst file and put your suggestion there. Let's separate this discussion from adding SYCL platform.

changes comparing to impl/llvm:

What is impl/llvm? Do you mean intel/llvm repository?

thanks for suggestion, done #171867
@bader @tahonermann @AlexeySachkov @sergey-semenov @vinser52 it would be nice to get your opinion. I am not able to add you as reviewers to llvm-project PRs so inviting directly. Thanks.

tahonermann

A few additional comments and some responses to previous ones.

tahonermann · 2025-12-10T19:04:22Z

libsycl/include/sycl/__impl/detail/obj_utils.hpp

+#ifdef __SYCL_DEVICE_ONLY__
+    (void)Obj;
+    return 0;


If this function won't implement useful semantics when compiled for the device, can we at least have it trap at run-time instead of returning a valid object that doesn't satisfy the function postconditions? E.g., __builtin_unreachable()?

can we at least have it trap at run-time instead of returning a valid object that doesn't satisfy the function postconditions? E.g., __builtin_unreachable()?

This automatically assumes, that the underlying device compiler (and any formats for representing device code) support such semantics. That is not the case for SPIR-V, as far as I know, for example.

What is the reason for having the macro in the first place here? I can't imagine hash APIs being used from device code without violating some other restrictions or simply being a UB.

As such, triggering a compilation/link failure through an unresolved symbol wouldn't be a bad idea. We can just leave this function as a declaration-only for device code as well.

That is not the case for SPIR-V, as far as I know, for example.

https://godbolt.org/z/qd8fGTMrG . Shouldn't we see llvm-spirv fail here then?

This automatically assumes, that the underlying device compiler (and any formats for representing device code) support such semantics.

That is still a good point though, we don't know about other targets like PTX.

What is the reason for having the macro in the first place here?

Not an expert in std headers implementation but it fails to compile https://godbolt.org/z/Eb94KMMed

I removed the macro completely for this code. the best case - we rely on compiler diagnostic, worst case - UB, since "implementations are not required to support device code that calls library functions from the C++ core language"

done in 002eeb3

libsycl/include/sycl/__impl/exception.hpp

libsycl/CMakeLists.txt

tahonermann · 2025-12-11T22:10:44Z

libsycl/include/sycl/__impl/detail/config.hpp

+#      define _LIBSYCL_DLL_LOCAL __attribute__((visibility("hidden")))
+#      define _LIBSYCL_EXPORT __attribute__((visibility("default")))


That's right; the C++11 attribute syntax is more restrictive in where it can be placed. Can we not use use the C++11 placement everywhere though? Or would that conflict with the syntax location required for Microsoft's __declspex(X) syntax? It would be great if we can standardize on the C++11 attribute placement requirements.

libsycl/include/sycl/__impl/exception.hpp

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

libsycl/docs/index.rst

libsycl/include/sycl/__impl/detail/macro_definitions.hpp

libsycl/include/sycl/__impl/detail/obj_utils.hpp

libsycl/include/sycl/__impl/info/desc_base.hpp

libsycl/include/sycl/__impl/platform.hpp

libsycl/src/detail/offload/offload_utils.hpp

libsycl/tools/sycl-ls/CMakeLists.txt

libsycl/src/CMakeLists.txt

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

Fznamznon

Can we add a test on this stage?
Also some dumb comments from a brief look

libsycl/include/sycl/__impl/detail/macro_definitions.hpp

libsycl/include/sycl/__impl/detail/obj_utils.hpp

libsycl/include/sycl/__impl/exception.hpp

Fznamznon · 2025-12-15T20:06:28Z

libsycl/src/detail/offload/offload_topology.cpp

+      },
+      &Mapping);
+  // Now register all platforms and devices into the topologies
+  auto &OffloadTopologies = getOffloadTopologies();


LLVM coding guidelines suggest using auto only when the type is obvious, i.e. cases like auto* a = dyn_cast<type>(b), will that be the case for libsycl?

Honestly I don't think it is important to show exact type here. it is pretty obvious from code that it is a container and we have exact element type shown 2 lines below.

libsycl/src/detail/offload/offload_topology.cpp

Fznamznon · 2025-12-15T20:09:13Z

libsycl/src/detail/offload/offload_utils.cpp

+  // case OL_PLATFORM_BACKEND_LEVEL_ZERO:
+  //   return backend::level_zero;


Is there plans for level 0?
Perhaps it makes sense to leave a comment saying coming soon.

yes, I expected this PR with L0 support to be merged much faster #158900 but it is still on review. Once it's merged these lines much be uncommented. May be I will be able to uncomment them before the merge of my PR.

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova · 2025-12-16T12:18:14Z

Can we add a test on this stage? Also some dumb comments from a brief look

I'd like to but we don't have CI ready.
With switch to liboffload I have to build all stack: LLVM, openmp, liboffload and only then libsycl so github-hosted runners are not able to deal with a huge build and run out of memory.
we are actually adding our runner and libsycl build on it llvm/llvm-zorg#668 but it isn't merged yet.
meanwhile I am working on LIT configs for libsycl to add check-sycl. Once CI runner is added and I am ready with configs I will create PR with basic test for this and device (next PR) functionality.

tahonermann

I got through much of the rest of the code today. I hope to get through the rest tomorrow.

tahonermann · 2025-12-17T21:19:08Z

libsycl/include/sycl/__impl/backend.hpp

+namespace detail {
+template <typename T> struct is_backend_info_desc : std::false_type {};
+} // namespace detail


detail::is_backend_info_desc doesn't appear to be used in this PR. Should it be omitted for now? I see platform::get_backend_info() isn't implemented yet.

that's intentional and aligned with intel/llvm.
SYCl 2020 spec declare get_backend_info method but doesn't specify anything that can be queried via this method.
So now it is declared but not defined and there is no such type T that can be used for compilation of this code.

tahonermann · 2025-12-17T21:41:00Z

libsycl/include/sycl/__impl/detail/macro_definitions.hpp

+#ifndef _LIBSYCL___IMPL_DETAIL_MACRO_DEFINITIONS_HPP
+#define _LIBSYCL___IMPL_DETAIL_MACRO_DEFINITIONS_HPP
+
+static_assert(__cplusplus >= 201703L, "Libsycl requires C++17 or later.");


Testing the value of __cplusplus will require compilation with the /Zc:__cplusplus option when compiling with MSVC (documentation). We can avoid pushing that requirement on users by checking the _MSVC_LANG predefined macro when compiling with MSVC instead (documentation).

Suggested change

static_assert(__cplusplus >= 201703L, "Libsycl requires C++17 or later.");

#if defined(_MSC_VER)

static_assert(_MSVC_LANG >= 201703L, "Libsycl requires C++17 or later.");

#else

static_assert(__cplusplus >= 201703L, "Libsycl requires C++17 or later.");

#endif

Yes, this is super annoying.

thank you, done 9b4b779

tahonermann · 2025-12-17T22:16:37Z

libsycl/include/sycl/__impl/detail/obj_utils.hpp

+// Note! This class relies on the fact that all SYCL interface
+// classes contain "impl" field that points to implementation object. "impl"
+// field should be accessible from this class.


Why is the pointer-to-impl idiom being used so extensively? I'm personally not a fan of it for performance reasons. If the reason is to create an ABI boundary, I think there are better ways to do that.

I believe that main justification is that pimpl idiom fits into common reference semantics really well https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:reference-semantics.

tahonermann · 2025-12-17T22:38:06Z

libsycl/include/sycl/__impl/info/platform.hpp

+};
+struct vendor : detail::info_desc_tag<vendor, sycl::platform> {
+  using return_type = std::string;
+};


No support for platform::extensions? Or just not yet? I understand that interface is deprecated.

I expect it to be "not just yet". I am temporally skipping deprecated features or features that are not needed for Phase 0.
Plus I expect it to be dependent on device impl.

platform``: deprecated info descriptor is not implemented (info::platform::extensions), to implement on RT level with ``device::get_info<info::device::aspects>()

https://github.com/KseniyaTikhomirova/llvm-project/pull/4/files#diff-e122f118f7e566d443f20bc82a475cbd291333a03b17a2d44b7b9d134dc45d80R96

tahonermann · 2025-12-17T22:41:14Z

libsycl/include/sycl/__impl/platform.hpp

-  /// Constructs a SYCL platform which contains the default device.
-  platform();


Why remove the default constructor for platform()? SYCL 2020 requires one. I guess it is because default_selector_v isn't yet implemented?

yes, that's correct

tahonermann · 2025-12-17T23:58:32Z

libsycl/src/detail/offload/offload_topology.hpp

+    if (PlatformId >= MDevRangePerPlatformId.size())
+      return {nullptr, 0};


Perhaps an assert would be appropriate here as well?

tahonermann · 2025-12-18T00:00:01Z

libsycl/src/detail/offload/offload_topology.hpp

+  std::vector<range_view<const ol_device_handle_t>>
+      MDevRangePerPlatformId; // PlatformDevices.size() == Platforms.size()


Should PlatformDevices and Platforms be MDevices and MPlatforms respectively?

tahonermann · 2025-12-18T00:01:38Z

libsycl/src/detail/offload/offload_utils.cpp

+#undef _OFFLOAD_ERRC
+
+  default:
+    return "Unknown error code";


Perhaps there should be an assertion here? Or this should be unreachable?

tahonermann · 2025-12-18T00:05:26Z

libsycl/src/detail/offload/offload_utils.hpp

+///
+/// \returns liboffload error code returned by API call.
+template <typename FunctionType, typename... ArgsT>
+ol_result_t call_nocheck(FunctionType &Function, ArgsT &&...Args) {


Perhaps rename to callNoCheck() for consistency?

tahonermann · 2025-12-18T00:05:42Z

libsycl/src/detail/offload/offload_utils.hpp

+///
+/// \throw sycl::runtime_exception if the call was not successful.
+template <typename FunctionType, typename... ArgsT>
+void call_and_throw(FunctionType &Function, ArgsT &&...Args) {


Perhaps rename to callAndThrow() for consistency?

could you please review style guideline I proposed for libsycl? #171867
once we align on it, I will walk through all code and align all names with it.

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova mentioned this pull request Nov 7, 2025

[SYCL] Add platform enumeration and info query using liboffload KseniyaTikhomirova/llvm-project#1

Closed

aelovikov-intel reviewed Nov 7, 2025

View reviewed changes

tahonermann self-requested a review November 17, 2025 18:07

AlexeySachkov reviewed Nov 17, 2025

View reviewed changes

add partial spec and base for std::hash support

bcb2711

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

aelovikov-intel mentioned this pull request Nov 18, 2025

[Offload] Generate OffloadTypedGetInfo.inc #168615

Closed

aelovikov-intel reviewed Nov 18, 2025

View reviewed changes

libsycl/src/detail/platform_impl.hpp Outdated Show resolved Hide resolved

aelovikov-intel reviewed Nov 19, 2025

View reviewed changes

libsycl/include/sycl/__impl/platform.hpp Outdated Show resolved Hide resolved

libsycl/include/sycl/__impl/exception.hpp Outdated Show resolved Hide resolved

KseniyaTikhomirova added 5 commits November 19, 2025 05:43

fix comments

b15b6c0

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

early init of platforms

88d313c

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

remove unique_ptr, make ref const, add operator==

849fed9

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

fix installation

7f62590

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

fix format

f081eea

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova requested a review from aelovikov-intel November 20, 2025 11:32

pbalcer reviewed Nov 20, 2025

View reviewed changes

aelovikov-intel reviewed Nov 20, 2025

View reviewed changes

remove offload codes from distributed headers

2224ab8

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

aelovikov-intel mentioned this pull request Nov 26, 2025

[SYCL][NFC] Cache the sycl::device instance in queue_impl intel/llvm#20764

Draft

KseniyaTikhomirova added 2 commits November 27, 2025 04:00

change ref to impl to raw ptr

71dcdf9

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

add asserts for impl

51529c1

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova requested review from AlexeySachkov, aelovikov-intel, bader, lplewa and pbalcer November 27, 2025 12:08

KseniyaTikhomirova commented Dec 3, 2025

View reviewed changes

libsycl/src/detail/platform_impl.hpp Outdated Show resolved Hide resolved

KseniyaTikhomirova commented Dec 4, 2025

View reviewed changes

libsycl/src/detail/platform_impl.hpp Outdated Show resolved Hide resolved

KseniyaTikhomirova commented Dec 4, 2025

View reviewed changes

libsycl/include/sycl/__impl/detail/obj_base.hpp Outdated Show resolved Hide resolved

KseniyaTikhomirova commented Dec 4, 2025

View reviewed changes

libsycl/src/detail/global_objects.cpp Outdated Show resolved Hide resolved

KseniyaTikhomirova added 2 commits December 5, 2025 04:10

fix comments

e4e6fd2

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

remove file common.hpp

e8e2811

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

tahonermann requested changes Dec 9, 2025

View reviewed changes

Fznamznon added the SYCL https://registry.khronos.org/SYCL label Dec 11, 2025

fix code-review comments

9ce7695

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova mentioned this pull request Dec 11, 2025

[SYCL] Add CodingGuidelines.rst for libsycl #171867

Open

tahonermann reviewed Dec 11, 2025

View reviewed changes

fix more comments

9653e23

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova force-pushed the add_get_platforms branch from 20d562d to 9653e23 Compare December 12, 2025 14:37

dvrogozh reviewed Dec 12, 2025

View reviewed changes

KseniyaTikhomirova added 3 commits December 15, 2025 02:00

fix doc

885947b

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

fix comments

656227b

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

remove device macro from hash impl

002eeb3

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova requested review from dvrogozh and tahonermann December 15, 2025 10:43

KseniyaTikhomirova added 2 commits December 15, 2025 05:15

Merge branch 'main' into add_get_platforms

72ee9cd

remove from backend enum

fb91c2b

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

Fznamznon reviewed Dec 15, 2025

View reviewed changes

fix comments

c90c2a7

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

KseniyaTikhomirova mentioned this pull request Dec 16, 2025

[SYCL] Add sycl::device KseniyaTikhomirova/llvm-project#4

Open

tahonermann requested changes Dec 18, 2025

View reviewed changes

fix comments

9b4b779

Signed-off-by: Tikhomirova, Kseniya <kseniya.tikhomirova@intel.com>

		# define _LIBSYCL_DLL_LOCAL __attribute__((visibility("hidden")))
		# define _LIBSYCL_EXPORT __attribute__((visibility("default")))

		// case OL_PLATFORM_BACKEND_LEVEL_ZERO:
		// return backend::level_zero;

		/// Constructs a SYCL platform which contains the default device.
		platform();

		if (PlatformId >= MDevRangePerPlatformId.size())
		return {nullptr, 0};

		std::vector<range_view<const ol_device_handle_t>>
		MDevRangePerPlatformId; // PlatformDevices.size() == Platforms.size()

[SYCL] Add platform enumeration and info query using liboffload #166927

Are you sure you want to change the base?

[SYCL] Add platform enumeration and info query using liboffload #166927

Uh oh!

Conversation

KseniyaTikhomirova commented Nov 7, 2025

Uh oh!

KseniyaTikhomirova commented Nov 7, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KseniyaTikhomirova Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KseniyaTikhomirova Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aelovikov-intel Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

KseniyaTikhomirova commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bader commented Dec 8, 2025

Uh oh!

tahonermann left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

KseniyaTikhomirova Nov 17, 2025 •

edited

Loading

KseniyaTikhomirova Dec 5, 2025 •

edited

Loading

aelovikov-intel Nov 20, 2025 •

edited

Loading

KseniyaTikhomirova commented Dec 8, 2025 •

edited

Loading

Fznamznon Dec 12, 2025 •

edited

Loading

KseniyaTikhomirova Dec 15, 2025 •

edited

Loading

Fznamznon Dec 15, 2025 •

edited

Loading