[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

Ronan Keryell via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 31 13:47:24 PDT 2021


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



More information about the cfe-commits mailing list