keryell added inline comments.
================ Comment at: clang/docs/SYCLSupport.md:73 +the integration header is used (included) by the SYCL runtime implementation, so +the header must be available before the host compilation starts.* + ---------------- bader wrote: > Naghasan wrote: > > > First, it must be possible to use any host compiler > > > > I don't understand the link with the integration header. SYCL being > > implementable as a library is a design principle of the specs but it > > doesn't means the clang host compiler has to remain a vanilla C++ compiler. > > > > > information provided in the integration header is used (included) by the > > > SYCL runtime implementation, so the header must be available before the > > > host compilation starts > > > > Another approach to the integration header would be for clang as the host > > compiler to generate the used type traits. > > > First, it must be possible to use any host compiler > > > > I don't understand the link with the integration header. SYCL being > > implementable as a library is a design principle of the specs but it > > doesn't means the clang host compiler has to remain a vanilla C++ compiler. > > > > > information provided in the integration header is used (included) by the > > > SYCL runtime implementation, so the header must be available before the > > > host compilation starts > > > > Another approach to the integration header would be for clang as the host > > compiler to generate the used type traits. > > If there are no objections from @keryell, I'd like to prototype this approach > for SYCL first to make sure there are no blocking issues. > This option seems to be worth to explore considering integration header > approach disadvantages. > > > First, it must be possible to use any host compiler > > > > I don't understand the link with the integration header. SYCL being > > implementable as a library is a design principle of the specs but it > > doesn't means the clang host compiler has to remain a vanilla C++ compiler. > > > > > information provided in the integration header is used (included) by the > > > SYCL runtime implementation, so the header must be available before the > > > host compilation starts > > > > Another approach to the integration header would be for clang as the host > > compiler to generate the used type traits. Type traits are somehow misleading and probably implementation details. I guess what this means is a meta-representation of the kernels and their API/ABI. > If there are no objections from @keryell, I'd like to prototype this approach > for SYCL first to make sure there are no blocking issues. > This option seems to be worth to explore considering integration header > approach disadvantages. No objection. triSYCL did not have this integration header since we were using Clang as the host compiler and were able to generate directly the kernel call on the host https://github.com/triSYCL/llvm/blob/sycl/master/lib/SYCL/SYCLSerializeArguments.cpp and the kernel stub on device https://github.com/triSYCL/llvm/blob/sycl/master/lib/SYCL/SYCLSerializeArgumentsInside.cpp Obviously, it was in the context of late outlining in LLVM but it can work with early outlining in Clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99190/new/ https://reviews.llvm.org/D99190 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
