C++ Modules Do Not Work with SYCL

[BenBrock]

C++ modules do not seem to currently work with intel/llvm when SYCL is used. I'm curious if this is likely to be added in the near future, or if there are architectural reasons that prevent C++ modules from working with intel/llvm.

I've written a minimal reproducer here: modules.tar.gz

To Reproduce In my minimal reproducer I create two modules. One of them uses SYCL, and this generates a pcm: invalid file type specified error, while the other compiles successfully.

(base) bbrock@ortce-skl22:~/src/issues/modules$ make
clang++ -std=c++2b --precompile -x c++-module test.cpp
clang++ -std=c++20 -c test.pcm
clang++ example.cpp -o example -std=c++2b -fprebuilt-module-path=. test.o
clang++ -fsycl -std=c++2b --precompile -x c++-module test-sycl.cpp
/nfs/site/home/bbrock/pkg/dpcpp-2023-04-17/bin/clang-offload-bundler: error: 'pcm': invalid file type specified
clang++: error: clang-offload-bundler command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:21: test-sycl.pcm] Error 1
(base) bbrock@ortce-skl22:~/src/issues/modules$ 

Environment (please complete the following information):

I'm using a recent commit of intel/llvm

(base) bbrock@ortce-skl22:~/src/issues/modules$ clang++ --version
clang version 17.0.0 (https://github.com/intel/llvm.git 554ed2187d320bb3d18616a439e9b867a5aff10d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nfs/site/home/bbrock/pkg/dpcpp-2023-04-17/bin

Additional context I'm working on the distributed ranges project, where we're writing a lot of templated SYCL code. Compile times are growing, and we'd like to use modules if/when they are available. Our CI currently takes around 20 minutes in the build/test phase, the majority of which is spent compiling. My concern though is more about the user experience. Most of our users will probably be on Aurora and other supercomputers, where the file systems tend to be slow. We need to use any tricks we can to speed up compile times, and modules could potentially help significantly by pre-processing header files.

[AlexeySachkov]

Hi @BenBrock,

C++ modules do not seem to currently work with intel/llvm when SYCL is used. I'm curious if this is likely to be added in the near future, or if there are architectural reasons that prevent C++ modules from working with intel/llvm.

I'm not aware of any plans to add modules support. Neither is I know whether there are any fundamental issues with enabling modules for SYCL - most likely no one has ever tried or investigated, because for a while we have been mostly focused on making the language implementation feature-reach and good enough quality-wise.

Such infrastructure/ecosystem features has had lower priority. As you can guess from #9689, pre-compiled headers are also not supported in -fsycl mode and it seems like our current stand is to make that clear by adding diagnostic messages, instead of implementing support for it.

I will re-classify this as "enhancement", because it is a valid feature request and something which we should probably consider to implement. It will be put into our backlog with updates posted here (if any, can't promise anything).

In general, about user experience around compile/link time I can share the following:

• there will be a switch to a new offloading model (different tools used under the hood). It will present opportunities to reduce amount of external calls, reduce amount of I/O and significantly shorten the path to enable thinLTO in our toolchain (which will reduce link time and potentially improve performance of generated code). See #8658
• there are ideas going around to try and implement so-called "1-pass" compilation approach, where front-end will be invoked once for both host and device code, which should reduce compilation time. There is no design document available at the moment, but some preparatory work has already started (#8917)

[kjeffery]

I spent a good afternoon trying to get SYCL to work with C++ modules but never found this post until I made the compiler crash. Consider this a vote for module support.