Detection of the compiler, of the language and of the side of the compilation pass: the one place where TDLS identifies the toolchain and the pass. Tests of a compiler version or of an architecture level stay where they serve, on top of these macros. More...

This graph shows which files directly or indirectly include this file:

Macros
#define	TDLS_DETAIL_PASS_HOST
	The host.

#define	TDLS_DETAIL_TARGET_GPU 0
	The pass generates CPU code.

#define	TDLS_TARGET_GPU TDLS_DETAIL_TARGET_GPU
	1 when the code is meant for a GPU, 0 for a CPU: what the defaults that depend on the hardware read (ArrowheadLUppConfig::block_row_interchange Auto, ArrowheadLUppConfig::rhs_pass_width -1). They shape the work of one solve only; TiledLUpp and CooperativeLUpp, whose factors can cross from the device to the host, reject RowInterchange::Auto. Deduced from the side of the pass (TDLS_DETAIL_TARGET_GPU). Where the pass cannot tell, it guesses the GPU: the generic mode of AdaptiveCpp, compiled for the device at run time, and the SPIR-V passes of SYCL and OpenMP, which an OpenCL CPU runs as well. -DTDLS_TARGET_GPU=0 (or 1) overrides the guess; a wrong value costs speed, never results. Under nvc++ with CUDA, one pass for the host and the device, the deduced value holds in constant expressions only: at run time, host code takes the CPU defaults and device code the GPU ones (NV_IF_TARGET), unless TDLS_TARGET_GPU is given.

Detailed Description

Detection of the compiler, of the language and of the side of the compilation pass: the one place where TDLS identifies the toolchain and the pass. Tests of a compiler version or of an architecture level stay where they serve, on top of these macros.

Author: Tristan Chenaille

Copyright: Copyright (C) 2026 CEA. All rights reserved. This project is publicly released under the BSD 3-Clause License (see the LICENSE file). CEA may also distribute it under specific licensing conditions.

Every macro below is internal (TDLS_DETAIL_) and defined when its condition holds; the headers that depend on the target include this one and test these macros instead of those of the toolchains.

Compilers:

TDLS_DETAIL_COMPILER_CLANG: clang and its derivatives (icpx, amdclang++, clang-cl);
TDLS_DETAIL_COMPILER_GCC: GCC, and the compilers that take its pragmas without being clang (nvc++);
TDLS_DETAIL_COMPILER_MSVC: MSVC itself, not clang-cl;
TDLS_DETAIL_COMPILER_GNU_ATTRIBUTES: a compiler of the GNU attributes (GCC, clang and their derivatives);
TDLS_DETAIL_COMPILER_NVCC: nvcc;
TDLS_DETAIL_COMPILER_NVCXX: nvc++;
TDLS_DETAIL_CODEGEN_NVCXX: code that nvc++ generates, under nvc++ and in the host pass of nvcc over nvc++, not in its device pass (the workarounds of nvc++ in core/macros.hpp);
TDLS_DETAIL_COMPILER_HIP_CLANG: the clang of HIP (hipcc, amdclang++, clang -x hip), the compiler of the HIP language on AMD.

Languages, for the function-space decorations:

TDLS_DETAIL_LANG_HIP: HIP, on AMD (clang) or on NVIDIA (hipcc over nvcc);
TDLS_DETAIL_FRONTEND_CUDA: a CUDA front end (nvcc, clang -x cuda), HIP over nvcc included;
TDLS_DETAIL_LANG_CUDA: CUDA, when not HIP;
TDLS_DETAIL_LANG_SYCL_DEVICE: the device pass of SYCL, whatever the device.

Side of the compilation pass, exactly one of:

TDLS_DETAIL_PASS_HOST: host code, run by the CPU;
TDLS_DETAIL_PASS_CUDA: the device pass of the CUDA language on NVIDIA (nvcc, clang);
TDLS_DETAIL_PASS_NVPTX: an NVIDIA device pass outside the CUDA language (OpenMP offloading of clang, DPC++ for NVIDIA);
TDLS_DETAIL_PASS_AMDGCN: an AMD device pass (HIP, OpenMP offloading, SYCL for AMD);
TDLS_DETAIL_PASS_SPIRV: a SPIR-V device pass (SYCL, OpenMP offloading): Intel GPUs, or any OpenCL device;
TDLS_DETAIL_PASS_GCC_OFFLOAD: an offloading pass of GCC (nvptx, amdgcn);
TDLS_DETAIL_PASS_NVCXX_CUDA: nvc++ with CUDA (-cuda, -stdpar=gpu), host and device code in one pass, which NV_IF_TARGET tells apart;
TDLS_DETAIL_PASS_NVCXX_OFFLOAD: OpenMP or OpenACC offloading of nvc++ without -cuda;
TDLS_DETAIL_PASS_NVCXX_STDPAR_OPENACC: the parallel algorithms of nvc++ through its OpenACC backend;
TDLS_DETAIL_PASS_ACPP_GENERIC: the generic mode of AdaptiveCpp, host and device code in one pass.

The order matters. clang defines CUDA_ARCH in the OpenMP device pass for AMDGCN up to clang 18, and DPC++ does not define it for NVPTX: the AMDGCN and NVPTX macros are tested first. AdaptiveCpp defines NVPTX in the host pass of its CUDA mode too, and the host pass of HIP defines AMDGCN, plus SPIRV for amdgcnspirv: the device macros count only outside the host passes of these languages. Every other SPIR-V device pass, SYCL or OpenMP, follows. The generic mode of AdaptiveCpp, recognized by the macro its compiler defines, comes last among the device passes.

Hardware of the pass:

TDLS_DETAIL_TARGET_GPU: 1 when the pass generates GPU code, every side but the host, 0 otherwise. The single-pass compilers (NVCXX_CUDA, ACPP_GENERIC) count as GPU, their code being meant for it, and so does a SPIR-V pass, whatever its device. The defaults that depend on the hardware (the elimination of the blocks of ArrowheadLUpp) read it: a wrong guess costs speed, never results, as they shape only the work of one call, never data kept between calls.

Macros

Detailed Description