[clang] [module] Can we compile an `-x cuda` or `-x hip` C++ file into a `C++20 Module`?

[anonymouspc]

clang supports clang -x cuda <file.cpp> to compile a cuda source/header. clang also supports clang -x c++-module --precompile <file.cpp> to compile a C++20-module.

Can we use it together? Then we can make a cuda header into a module, which greatly bursts compile time. I wonder is this tended to be in future plan :)

Thank you!

[Artem-B]

My understanding is that modules can be used only when used with exactly identical compiler options. Right now it makes it impossible to use with the complete CUDA compilation, because host and device sub-compilations use different compiler options.

The best we can do right now is to try using modules for the host compilation only, and disable them for the GPU sub-compilations, but I suspect that will surface other issues. I.e. for the distributed compilation, is the build system expected to stage the module files, full set of headers, or both?

Long term, to support CUDA, module support may need to relax its requirements on the compiler options to support multiple sub-compilations, or carry multiple module variants so GPU sub-compilations can use them. I'm not sure if that's feasible, because the GPU side of the compilation may sometimes be substantially different from the host. In the worst case we may end up needing multiple complete sets of modules -- one for the host, and one per each GPU variant we target.

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: anonymous (anonymouspc)

`clang` supports `clang -x cuda <file.cpp>` to compile a cuda source/header. `clang` also supports `clang -x c++-module --precompile <file.cpp>` to compile a `C++20-module`.

Can we use it together? Then we can make a cuda header into a module, which greatly bursts compile time. I wonder is this tended to be in future plan :)

Thank you!

[ChuanqiXu9]

My understanding is that modules can be used only when used with exactly identical compiler options. Right now it makes it impossible to use with the complete CUDA compilation, because host and device sub-compilations use different compiler options.

The best we can do right now is to try using modules for the host compilation only, and disable them for the GPU sub-compilations, but I suspect that will surface other issues. I.e. for the distributed compilation, is the build system expected to stage the module files, full set of headers, or both?

Long term, to support CUDA, module support may need to relax its requirements on the compiler options to support multiple sub-compilations, or carry multiple module variants so GPU sub-compilations can use them. I'm not sure if that's feasible, because the GPU side of the compilation may sometimes be substantially different from the host. In the worst case we may end up needing multiple complete sets of modules -- one for the host, and one per each GPU variant we target.

We can relax the requirement. Look for Benign in LangOptions.def. There are the "white" list.

Or we can have new mechanism to handle it if needed.

[Artem-B]

Well. All I can say is that preprocessed sources for the host and device sub-compilations are different within the same top-level compilation. Whether that difference is benign enough to be able to reuse the same header modules -- I do not know.

Look for Benign in LangOptions.def. There are the "white" list.

Looks like some of the options that are different betweek host/device are explicitly marked as incompatible. E.g. exceptions may be available/used on the host, but are generally not available on the GPU side.

The key option that differentiates host/device compilation -fcuda-is-device is also marked incompatible. Considering that the modules do care about AST being unchanged, -fcuda-is-device pretty much guarantees that modules will not work, as it affects function overload resolution.

I am now pretty certain that in order for the modules to work with CUDA, we'll need to build and carry GPU-specific module variants, and then get sub-compilations to pick the right variant.

[ChuanqiXu9]

Well. All I can say is that preprocessed sources for the host and device sub-compilations are different within the same top-level compilation. Whether that difference is benign enough to be able to reuse the same header modules -- I do not know.

Look for Benign in LangOptions.def. There are the "white" list.

Looks like some of the options that are different betweek host/device are explicitly marked as incompatible. E.g. exceptions may be available/used on the host, but are generally not available on the GPU side.

The key option that differentiates host/device compilation -fcuda-is-device is also marked incompatible. Considering that the modules do care about AST being unchanged, -fcuda-is-device pretty much guarantees that modules will not work, as it affects function overload resolution.

I am now pretty certain that in order for the modules to work with CUDA, we'll need to build and carry GPU-specific module variants, and then get sub-compilations to pick the right variant.

So it sounds like we need to build two different BMIs, one for host and one for device.