SYCL include path problem

[ye-luo]

Describe the bug

reproducer test_include.cpp

#include <CL/sycl.hpp>
int main()
{ }

My intention is to call SYCL runtime library.
For this minimal SYCL code, I expect the needed include path is /opt/intel/oneapi/compiler/2022.0.2/linux/include/sycl.

$ icpx --std=c++17 -I/opt/intel/oneapi/compiler/2022.0.2/linux/include/sycl test_include.cpp
In file included from test_include.cpp:1:
In file included from /opt/intel/oneapi/compiler/2022.0.2/linux/include/sycl/CL/sycl.hpp:11:
In file included from /opt/intel/oneapi/compiler/2022.0.2/linux/include/sycl/CL/sycl/accessor.hpp:13:
/opt/intel/oneapi/compiler/2022.0.2/linux/include/sycl/CL/sycl/buffer.hpp:17:10: fatal error: 'sycl/ext/oneapi/accessor_property_list.hpp' file not found
#include <sycl/ext/oneapi/accessor_property_list.hpp>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

For sure adding another include path does work

icpx -I/opt/intel/oneapi/compiler/2022.0.2/linux/include/sycl -I /opt/intel/oneapi/compiler/2022.0.2/linux/include test_include.cpp

but why adding this burden to users?

I know -fsycl can hide the include problem but sycl should be allowed to use as a normal host library without relying on -fsycl.
It currently does work without -fsycl, however the include paths are messy.

The issue shows up similarly with GCC.

g++ --std=c++17 -I/opt/intel/oneapi/compiler/2022.0.2/linux/include/sycl -I /opt/intel/oneapi/compiler/2022.0.2/linux/include test_include.cpp -lsycl

after adding two include, g++ compiles the reproducer.

So it is not a compiler issue but a SYCL library issue

How about removing all the first sycl from all the include line for sycl extension and allow user to specify one include path only?

llvm/sycl/include/CL/sycl/buffer.hpp

Line 17 in 0b456ce

#include <sycl/ext/oneapi/accessor_property_list.hpp>

To Reproduce
Please describe the steps to reproduce the behavior:

See above

Environment (please complete the following information):

• OS: LInux
• Target device and vendor: running on host
• DPC++ version: Intel(R) oneAPI DPC++/C++ Compiler 2022.0.0 (2022.0.0.20211123)
• Dependencies version: compilation issue

[alexbatashev]

I'd say, this is more of a feature request, rather than a bug. We do not currently test SYCL runtime outside the -fsycl environment, neither we officially support that use-case. I agree there may be value in skipping device side compiler, but that is not something we've considered carefully in the past.

[0x12CC]

@ye-luo, is there a reason you want to use the SYCL headers without the -fsycl compilation flag? Both include arguments are needed since our headers depend on them being in the compiler include paths. Note that we don't support SYCL compilation without the -fsycl flag.

[ye-luo]

-fsycl compiles source code twice, once for the host and once for the device. It is time consuming. So better to add -fyscl only when compiling sycl kernels not sycl runtime calls. For example, I use sycl API to manage GPU memories and wrap it as a C++ allocator in a header file then it is propagated to many files. What I need is host runtime compilation only.

[ye-luo]

Here is an up-to-date reproducer.

#include <sycl/sycl.hpp>
int main()
{ }

icpx error

$ icpx -I/opt/intel/oneapi/compiler/latest/include main.cpp
In file included from main.cpp:1:
In file included from /opt/intel/oneapi/compiler/latest/include/sycl/sycl.hpp:25:
In file included from /opt/intel/oneapi/compiler/latest/include/sycl/accessor.hpp:14:
/opt/intel/oneapi/compiler/latest/include/sycl/atomic.hpp:11:10: error: 'CL/__spirv/spirv_types.hpp' file not found with <angled> include; use "quotes" instead
   11 | #include <CL/__spirv/spirv_types.hpp>         // for Scope, MemorySemanticsMask
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |          "CL/__spirv/spirv_types.hpp"
In file included from main.cpp:1:
In file included from /opt/intel/oneapi/compiler/latest/include/sycl/sycl.hpp:25:
In file included from /opt/intel/oneapi/compiler/latest/include/sycl/accessor.hpp:14:
In file included from /opt/intel/oneapi/compiler/latest/include/sycl/atomic.hpp:14:
/opt/intel/oneapi/compiler/latest/include/sycl/detail/helpers.hpp:24:10: fatal error: 'CL/__spirv/spirv_types.hpp' file not found
   24 | #include <CL/__spirv/spirv_types.hpp> // for MemorySemanticsMask

g++ error

$ g++ -I/opt/intel/oneapi/compiler/latest/include main.cpp
In file included from /opt/intel/oneapi/compiler/latest/include/sycl/accessor.hpp:14,
                 from /opt/intel/oneapi/compiler/latest/include/sycl/sycl.hpp:25,
                 from main.cpp:1:
/opt/intel/oneapi/compiler/latest/include/sycl/atomic.hpp:11:10: fatal error: CL/__spirv/spirv_types.hpp: No such file or directory
   11 | #include <CL/__spirv/spirv_types.hpp>         // for Scope, MemorySemanticsMask
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Why is spirv exposed when doing a host compilation. Such include only makes sense in the device compilation pass.

[AlexeySachkov]

-fsycl compiles source code twice, once for the host and once for the device. It is time consuming. So better to add -fyscl only when compiling sycl kernels not sycl runtime calls. For example, I use sycl API to manage GPU memories and wrap it as a C++ allocator in a header file then it is propagated to many files. What I need is host runtime compilation only.

Thanks for that info.

We are in process of upstreaming our SYCL implementation to regular clang - it will take a while, but along the way there will be some updates and changes done. In particular, we expect that there will be -fsycl-host-only mode added which should solve this issue. See llvm/llvm-project#117268 - once this is merged it will make its way to intel/llvm and eventually into icpx.

We still won't provide a guarantee that SYCL headers work outside of -fsycl environment, but at least there will be a path towards skipping unnecessary device compilation. Tagging @mdtoguchi for awareness in case any other changes are required for that beside the PR which is already on review.

[AlexeySachkov]

To give an update here: llvm/llvm-project#117268 introduced -fsycl-host-only flag which seems to be intended to solve this problem. However, it does not add any include paths to SYCL headers, simply because at the time we made that PR there was no SYCL headers in upstream. With llvm/llvm-project#144372 merged, now there are SYCL headers (even if they aren't functional yet). Now we can connect the two and this feature request will be complete