[SYCL RTC] Use in-memory libcxx/libc headers for SPIR-V targets#20502
Open
aelovikov-intel wants to merge 19 commits intointel:syclfrom
Open
[SYCL RTC] Use in-memory libcxx/libc headers for SPIR-V targets#20502aelovikov-intel wants to merge 19 commits intointel:syclfrom
aelovikov-intel wants to merge 19 commits intointel:syclfrom
Conversation
f54abd9 to
c9bdf63
Compare
c9bdf63 to
350e8f2
Compare
350e8f2 to
5c6f8b1
Compare
5c6f8b1 to
9d0562d
Compare
9d0562d to
2299dcb
Compare
2299dcb to
9032697
Compare
9032697 to
846f1c3
Compare
846f1c3 to
99376a1
Compare
99376a1 to
5506074
Compare
aelovikov-intel
commented
Nov 4, 2025
| - type: size_t | ||
| - type: size_t | ||
| - type: mbstate_t | ||
| - type: mbstate_t *__restrict |
Contributor
Author
There was a problem hiding this comment.
This and the one below are part of the upstream llvm/llvm-project#164666.
5506074 to
6fffeb8
Compare
srividya-sundaram
approved these changes
Nov 20, 2025
elizabethandrews
approved these changes
Nov 20, 2025
gmlueck
reviewed
Nov 21, 2025
sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_compiler.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_compiler.asciidoc
Outdated
Show resolved
Hide resolved
gmlueck
reviewed
Nov 24, 2025
sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_compiler.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_compiler.asciidoc
Outdated
Show resolved
Hide resolved
Contributor
Author
|
@intel/llvm-reviewers-runtime, Chris is on vacation, can somebody else take a look? |
cperkinsintel
approved these changes
Dec 1, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While resulting in extra restrictions to ensure not ABI-violations when
passing data between host and device, that makes distribution of SYCL
applications using SYCL RTC much easier, so we're willing to pay that
price. Kernel compiler extension is being updated accordingly.
Ideally, we'd like to use the same STL implementation as the host code,
but we cannot re-distribute GNU libstdc++/libc or MS C++/C
headers (including Windows SDK) due to legal restrictions, so we embed
LLVM's libcxx/libc headers instead.
The way SYCL (non-RTC) works is that we use the same host C++/C
headers for device compilation and ignore the actual
libc.so/libstdc++.so as we provide known entry points ourselves (be it
libclc/libdevice/etc.). As such, for SYCL RTC, we don't actually need to
build those runtimes for a gpu target either, and can just use the
headers they provide. However, libc implementation of
entrypoints/headers on Windows is very incomplete, but we don't really
need that. All we need is declarations of C Standard Library/POSIX
functions and there is a way to pass some extra defines/configs to make
it generate that. As such, we avoid
LLVM_ENABLE_RUNTIMESand insteadconfigure libcxx/libc as extra projects manually, passing needed option
and avoid full builds and installation for the regular host toolchain.o
Another caveat is that we have to disable system include paths (to
exclude regular libc headers as having two libc implementations is
causing all sorts of issues). As such, this approach isn't working for
CUDA/HIP targets that need corresponding SDKs. Previous behavior of
requiring/using system C++ toolchain is retained for those targets.