[FEA]: Expose compiler detection macros

[Jacobfaib]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct

Area

libcu++

Is your feature request related to a problem? Please describe.

Any mature downstream project will at some point care about which compiler is currently being invoked. Usually, people end up rolling their own compiler detection macros with varying levels of success.

Describe the solution you'd like

Expose the _CCCL_COMPILER(x) macros publicly (sans underscore) to users in a cuda/compiler_detection (name subject to bike-shedding) header.

Effectively do #3237 but as a public interface.

Describe alternatives you've considered

No response

Additional context

No response

[fbusato]

I fully support the initiative!!
Just to provide an example, all CUDA Math libraries reimplement these macros over and over.

[fbusato]

not only compilers, but also architectures, OS, and several others. See
https://nvidia.github.io/cccl/unstable/cccl/development/macro.html

[davebayer]

I agree, I think our compiler detection macros implementation is great and others would appreciate it

[fbusato]

see also the discussion here #2504

[davebayer]

I think the situation is different now, those macros are stable for quite some time now, they were relatively new back then

[jrhemstad]

My biggest concern here is if these are going to be public facing, how are we going to test that they do what they say they do? I don't want to have to broadly expand our test matrix to cover all possible versions of host compilers to verify them (likewise with any other platform specific macros).

[Jacobfaib]

I don't think we need to cover everything with explicit testing, because we probably don't need to expose everything. Put it this way, the most important traits that users would want to test for:

Compilers, i.e. ask "is the compiler...":

• clang
• gcc
• nvcc
• nvc++
• MSVC
• maybeee intel compilers, but unlikely

Systems, i.e. ask "is the current system...":

• Linux (any flavor of linux suffices for our purposes)
• macOS
• Windows

Compilation mode:

• Host compilation
• Device compilation
• Detecting various CUDA toolkit features (version, relocatable device code, dynamic parallelism, etc.)

All of these are already naturally covered by our existing testing. We could put in a single compiler_test.cpp with a few ifdefs and cover the full cartesian product of these conditions today.

As a bonus, I think we can claim to detect (but perhaps not exhaustively test):

• Endianness
• Other linux flavors
• Other more esoteric CUDA features, i.e. float128 support, half support, etc.

[jrhemstad]

That's still a pretty significant addition to the surface area of the public API for features that we don't really have any users asking for today.

These macros have undergone a pretty significant amount of churn and updates over the years as well which makes me reluctant to carve them into stone.

[miscco]

To reiterate my standpoint from the internal discussion:

We cannot make our internal macros public. We need the ability to break then when we see fit and we cannot wait for a deprecation cycle of 2 major releases to do so.

What we could do is add new public macros that forward / boil down to what we are using internally.

That would still be limited. We currently do not test for apple-clang or intel for example.

I believe there are some CUDA specific macros that would be useful, like

• _CCCL_CUDA_COMPILER
• _CCCL_CUDACC_AT_LEAST, _CCCL_CUDACC_BELOW
• _CCCL_CTK_AT_LEAST, _CCCL_CTK_BELOW
• _CCCL_PTX_ARCH
• __cccl_ptx_isa
• _CCCL_HOST_COMPILATION, _CCCL_DEVICE_COMPILATION, _CCCL_CUDA_COMPILATION

[jrhemstad]

We cannot make our internal macros public.

I believe it is implied we would add a layer of indirection between the publicly exposed macro and the internally used one.

[fbusato]

A level of indirection is perfectly fine. We don't need to expose a public version for all our internal macros (here the main ones). We can open a PR for each subset and decide what is meaningful.
If we decide to go in this direction, I will take care of reporting them to the official CUDA prog guide.

[jrhemstad]

@Jacobfaib @fbusato I believe a helpful next step would be to make it more concrete and start an MVP list of precisely which queries/macros we'd like to expose.