[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.

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]

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

FYI, published for review.

[KseniyaTikhomirova]

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:

1. all file names under libsycl folder (.h, .cpp, .md, etc) will be in snake_case (no exceptions)
2. SYCL API type names - follow SYCL2020 spec naming - snake_case
3. 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:

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

[bader]

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

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

1. all file names under libsycl folder (.h, .cpp, .md, etc) will be in snake_case (no exceptions)
2. SYCL API type names - follow SYCL2020 spec naming - snake_case
3. 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.

[KseniyaTikhomirova]

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

1. all file names under libsycl folder (.h, .cpp, .md, etc) will be in snake_case (no exceptions)
2. SYCL API type names - follow SYCL2020 spec naming - snake_case
3. 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.

[KseniyaTikhomirova]

FYI,

• I rebased PR to pick up L0 plugin landed recently.
• I aligned the code style with [SYCL] Add CodingGuidelines.rst for libsycl #171867

[tahonermann]

I finally got all the way through the PR. Most of the new suggestions are rewording of comments, but there are some questions buried in there too. Overall, the code looks nice and clean to me.

[KseniyaTikhomirova]

@tahonermann thank you for the review.
I have applied changes and replied to comments that I want to discuss before applying.

[tahonermann]

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:

1. should we even align style or it is good to go with what we have in intel/llvm

2. agree or not with proposed strategy

Just to close this question out. My personal preference would be to use the standard C++ and SYCL naming styles everywhere for two main reasons:

• It avoids the cognitive overhead of having to remember which style to use where.
• I find them easier to read than CamelCase.

That being said, this is only my personal preference and I don't think it should be given much, if any, weight in determining style policy for this project. I think you and @bader should decide what you think is best; there isn't a wrong answer.

[KseniyaTikhomirova]

@tahonermann thank you, I fixed the rest of the comments here 2767396

[KseniyaTikhomirova]

Rebased and checked locally:

$ sycl-ls
[level_zero:unknown]

$ sycl-ls -v
[level_zero:unknown]

Platforms: 1
Platform [#1]:
    Version  : v0.0.1
    Name     : LEVEL_ZERO
    Vendor   : Unknown platform vendor
    Devices  : unknown

[tahonermann]

Thanks @KseniyaTikhomirova! This looks good to me, so I'm accepting. I did add one minor suggestion for the added assertion for you to consider.