[SYCL] Move SYCL headers from standard clang location

[vladimirlaz]

SYCL headers were moved from default clang include directory
(lib/clang/11.0.0/include) to (lib/clang/11.0.0/include/sycl) to
support mixed compilers (e.g. gcc for host code and clang for
device code) during build of SYCL application.

Clang driver adds new directory to system include search path.

For non-clang compilers the user should add option below to
compiler command line to let it find SYCL headers:
-I <path_to_sycl_compiler>/include/sycl

Additional diagnostic can be raised depending on compiler
which is used (see examples for clang below). It can be ignored.

/localdisk2/bbsycl/res/include/sycl/CL/__spirv/spirv_ops.hpp:74:8: error: SYCL 1.2.1 specification does not allow 'sycl_device' attribute applied to a function with a raw pointer parameter type [-Wsycl-strict]
extern SYCL_EXTERNAL __ocl_event_t __spirv_GroupAsyncCopy(

/localdisk2/bbsycl/res/include/sycl/CL/sycl/ordered_queue.hpp:267:37: warning: 'ordered_queue' is deprecated: Replaced by in_order queue property [-Wdeprecated-declarations]
size_t operator()(const cl::sycl::ordered_queue &q) const {

Signed-off-by: Vladimir Lazarev vladimir.lazarev@intel.com

[bader]

I suggest moving SYCL header out of compiler headers directory i.e. not put them to lib/clang/11.0.0/include/.
Can we move them to include/sycl directory?

[Fznamznon]

could you please elaborate a bit more about this:

Additional diagnostic can be raised depending on compiler
which is used (see examples for clang below). It can be ignored.
/localdisk2/bbsycl/res/lib/clang/11.0.0/include/sycl/CL/__spirv/spirv_ops.hpp:74:8: error: SYCL 1.2.1 specification does not allow 'sycl_device' attribute applied to a function with a raw pointer parameter type [-Wsycl-strict]
extern SYCL_EXTERNAL __ocl_event_t __spirv_GroupAsyncCopy(
/localdisk2/bbsycl/res/lib/clang/11.0.0/include/sycl/CL/sycl/ordered_queue.hpp:267:37: warning: 'ordered_queue' is deprecated: Replaced by in_order queue property [-Wdeprecated-declarations]
size_t operator()(const cl::sycl::ordered_queue &q) const {

[vladimirlaz]

could you please elaborate a bit more about this:

Additional diagnostic can be raised depending on compiler
which is used (see examples for clang below). It can be ignored.
/localdisk2/bbsycl/res/lib/clang/11.0.0/include/sycl/CL/__spirv/spirv_ops.hpp:74:8: error: SYCL 1.2.1 specification does not allow 'sycl_device' attribute applied to a function with a raw pointer parameter type [-Wsycl-strict]
extern SYCL_EXTERNAL __ocl_event_t __spirv_GroupAsyncCopy(
/localdisk2/bbsycl/res/lib/clang/11.0.0/include/sycl/CL/sycl/ordered_queue.hpp:267:37: warning: 'ordered_queue' is deprecated: Replaced by in_order queue property [-Wdeprecated-declarations]
size_t operator()(const cl::sycl::ordered_queue &q) const {

As far as I understood compiler warnings are suppressed for system headers (found in path pointed by -internal-isystem). Once the path is added with -I (this is true if the user uses non-sycl compiler for building host code) extra warnings were generated by the compiler. I mentined here examples from LIT execution.
It is up to user to suppress them.

[vladimirlaz]

I suggest moving SYCL header out of compiler headers directory i.e. not put them to lib/clang/11.0.0/include/.
Can we move them to include/sycl directory?

Both locations are possible but I prefer current location because:

• I did not find good way to detect compiler root directory in clang driver. I will need to use .. symbols which might be error prone if there are symbolic links in the path. Current approach adds sub-folder which seems to be safer.
• There was a request to preserve high level layout to decrease impact on tools and infrastructure.

[bader]

I suggest moving SYCL header out of compiler headers directory i.e. not put them to lib/clang/11.0.0/include/.
Can we move them to include/sycl directory?

Both locations are possible but I prefer current location because:

• I did not find good way to detect compiler root directory in clang driver. I will need to use .. symbols which might be error prone if there are symbolic links in the path. Current approach adds sub-folder which seems to be safer.

Please take a look how standard library is handled.

• There was a request to preserve high level layout to decrease impact on tools and infrastructure.

This is a terrible reason to implement error-prone design.

[vzakhari]

I suggest moving SYCL header out of compiler headers directory i.e. not put them to lib/clang/11.0.0/include/.
Can we move them to include/sycl directory?

Both locations are possible but I prefer current location because:

• I did not find good way to detect compiler root directory in clang driver. I will need to use .. symbols which might be error prone if there are symbolic links in the path. Current approach adds sub-folder which seems to be safer.

Please take a look how standard library is handled.

• There was a request to preserve high level layout to decrease impact on tools and infrastructure.

This is a terrible reason to implement error-prone design.

Do we want to keep versioning for sycl header files the same way clang does for its header files? If yes, should the sycl header files' version match the clang version?

[bader]

I suggest moving SYCL header out of compiler headers directory i.e. not put them to lib/clang/11.0.0/include/.
Can we move them to include/sycl directory?

Both locations are possible but I prefer current location because:

• I did not find good way to detect compiler root directory in clang driver. I will need to use .. symbols which might be error prone if there are symbolic links in the path. Current approach adds sub-folder which seems to be safer.

Please take a look how standard library is handled.

• There was a request to preserve high level layout to decrease impact on tools and infrastructure.

This is a terrible reason to implement error-prone design.

Do we want to keep versioning for sycl header files the same way clang does for its header files? If yes, should the sycl header files' version match the clang version?

Maybe, but I don't think that moving library headers to the compiler sub-directory is the right approach or has any connection to the library versioning.
SYCL runtime library is a separate project and I prefer treating it that way.
E.g. libc++ is another LLVM project, which versioning following LLVM scheme, but libc++ headers are not installed into compiler built-in headers sub-directory. libc++ project uses CMake utilities to align versioning with the rest of the project and we might do the same.

[bader]

@vladimirlaz, please, resolve merge conflict and fix tests.

[vladimirlaz]

@vladimirlaz, please, resolve merge conflict and fix tests.

done

[bader]

@vladimirlaz, OpenCL headers not found during CTS compilation.

[bader]

LGTM with a couple of nits.

Please, rename a couple of CMake variables.