intel
[SYCL RTC] Use in-memory libcxx/libc headers for SPIR-V targets
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_RUNTIMES and instead
configure 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.
Summary from discussion with @gmlueck
- I'll try to switch default to use this new behavior by default
- Make extra sure none of the original system include paths are preserved
- Provide an option to revert to "old" behavior, use that for CUDA/HIP where system installation of the SDK is necessary
- All restrictions will be lifted from the option level to the whole kernel compiler extension level (with some cleanup there).
@gmlueck , did I miss anything?
Summary from discussion with @gmlueck
Yes, that looks good. We may have some more discussion on the restrictions once they are cleaned up, but we can discuss that later. In general, I'm OK with more restrictions initially which we then reduce over time.
I've changed the approach to enable new mode by default whenever possible. Also merged latest origin/sycl as some minor changes were implemented in other PRs.
This is a significant change from the last reviewed state, so please re-review. CMake logic was updated a lot too.
@intel/llvm-reviewers-runtime, Chris is on vacation, can somebody else take a look?