[SYCL] Add platform enumeration and info query using liboffload

[KseniyaTikhomirova]

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.

[KseniyaTikhomirova]

This PR is cut a little bit comparing to the one I planned for UR.

1. there is no CI workflows and any testing. offload build is done with dependency on llvm tools that are enabled by clang project so build is too heavy now. I double checked the possibility - GH runner was run out of space https://github.com/KseniyaTikhomirova/llvm-project/actions/runs/18717281129/job/53379831538. So Ci build & tests to be added after L0 plugin is merged and there workflows are added. I discussed joining SYCL RT build and L0 offload plugin and we agreed to join and share it to sync SYCL usage and liboffload API changes and keep both projects in healthy state.
2. I've mentioned testing of ABI many times but it can't be included because of the reason above plus to implement "final" version of ABI for classes (for example, exception) I need to have context and probably device classes done. So it should be done after the device/context and dependent classes platform/exception and whatever else is needed are ready.

In the end this PR:

1. adds dependency on liboffload
2. implements platform::get_platforms, get_info, get_backend on liboffload
3. adds draft of sycl-ls tool that enumerates platforms, queries platform info from offload. device data/presence is explicitly marked as unknown now since I don't have an implementation of device class. I added comments to the code where you can see the output.

I believe this PR is ready for internal review: @tahonermann, @dvrogozh, @asudarsa, @aelovikov-intel, @sergey-semenov, @bader, @againull, @YuriPlyakhin

[aelovikov-intel]

I had a brief look with some inline comments as I went. I think the high-level question we need to ask right now is this:

• Explicitly define naming convention (unlike the zoo in intel/llvm)
• Usage of LLVMSupport, at least under src/
• Should the approach to *_impl classes be revisited here
• [Less important] TblGen vs. macros + *.def files

Also + @vinser52

[aelovikov-intel]

I'd really like us to re-implement this in intel/llvm once our next ABI Breaking period opens (seems to be about a week away?) to have a single template base class abstracting this functionality away.

I also wonder how much it's even needed. AFAIK, those *_impl classes serve two main purposes:

• Backward ABI compatibility
• SYCL's common reference semantics

I'd argue that the ABI compatibility might not be necessary given that we plan to have versioning of the namespace and make actual use of it.

[vinser52]

@aelovikov-intel I agree with the idea of the base class.
Regarding the second part, if we get rid of pimpl pattern, it might cause ABI updates to occur much more frequently.

[sergey-semenov]

Having a base class makes sense to me too. The pimpl idiom maps cleanly onto common reference semantics though, so I wonder how you envision implementing that without it.

[aelovikov-intel]

class sycl::device {
public:
  device(const device &) = default;
  device(device &&) = default;
  device &operator=(const device &) = default;
  device &operator=(device &&) = default;
  inline friend operator==(..) = default;

private:
  ol_device_handle_t ol_device;
};

would satisfy the common reference semantics, wouldn't it? As such, for a device the only benefit of having device_impl would be for "caching" of things that aren't mapped directly to a liboffload API (e.g., sub-devices, maybe?).

[aelovikov-intel]

Regarding the second part, if we get rid of pimpl pattern, it might cause ABI updates to occur much more frequently.

inline namespace versioning is done at the outer namespace level, so once one class (including anything under sycl::detail::) needs an update, we provide an update in that minor release, 6 months cadence in upstream, IIUC.

As such, I don't think (or maybe hope?) the actual increase in frequency for the project as a whole would be significant.

[aelovikov-intel]

I don't think "ABI neutral" should be upstreamed at all. And if it should, then everything should be STL-agnostic at the ABI boundary.

Also, any idea how std::exception deals with that (e.g., in libcxx)?

[KseniyaTikhomirova]

Some time ago I asked Greg if we should support both ABIs and the answer was: "Yes, I think we want to upstream the CXX11_ABI stuff." So we do want to support it.

regarding libcxx I will check

[aelovikov-intel]

@gmlueck , why do we need that? AFAIK, upstream PyTorch has finally moved to C++11 ABI, e.g.:

• https://discuss.pytorch.org/t/why-is-libtorch-from-pip-not-build-with-cxx11-abi/207765/2
• Nightly pytorch wheel for prerelease version 2.6 is build with C++11 ABI on, at least for CPU pytorch/pytorch#143962 (comment)

and nobody is using the ancient pre-C++11 one.

[gmlueck]

Are you asking about what we should upstream, or are you asking what we should support in our downstream "intel/llvm" repo? If we do not upstream the ABI neutral stuff, but we keep it in downstream, won't that be a pain whenever we pull from upstream?

[aelovikov-intel]

Emm, yes?.. But that's still a terrible argument for upstreaming that.

[gmlueck]

If there are still customers that need this functionality, why wouldn't we upstream it? If there are no customers that want it, then should we propose to remove it also from "intel/llvm"?

[aelovikov-intel]

This whole solution was a quick hack. The root cause of the problem is the dependency of our ABI to a particular STL. Even if we want to support this usage scenario, the proper fix would be to avoid any STL data types crossing ABI boundary, not just std::string.

[dvrogozh]

I think it's better to focus on the current and future usages rather than hold on and support older and outdated ones. Those who needs older support can still use those older releases which have it. It's actually important to encourage users to switch to newer stuff. When you are working on upstreaming changes, above becomes a rule as it's rarely of interest of community what were historic customized usages in the closed source solution.

[bader]

LGTM in general.

[vinser52]

@aelovikov-intel I agree with the idea of the base class.
Regarding the second part, if we get rid of pimpl pattern, it might cause ABI updates to occur much more frequently.

[KseniyaTikhomirova]

just for me to summarize the keys comments left:

• spinlock vs mutex usage
• base class for sycl impl obj
• CXX ABI suggestion
• tblgen usage to explore
• llvm utilities usage to explore

[vinser52]

Another question: do we handle somewhere the list of exported symbols? Today, it is hard to control which symbols are exported by the library.

[KseniyaTikhomirova]

Another question: do we handle somewhere the list of exported symbols? Today, it is hard to control which symbols are exported by the library.

not yet. #1 (comment)

[KseniyaTikhomirova]

I either fixed or replied to all comments. So I think this PR is ready for the second round of review, thanks.

[bader]

Still LGTM :).

[bader]

Suggested change

	// Virtual inheritance is mandated by SYCL2020.
	// Virtual inheritance is mandated by SYCL 2020.

[KseniyaTikhomirova]

this PR is public now llvm#166927