Date: Sat, 30 Aug 2025 13:45:20 -0700
On Saturday, 30 August 2025 12:28:22 Pacific Daylight Time Tiago Freire via
Std-Discussion wrote:
> Ex. x86_64 could have the preprocessor directive "x86_64" no matter the
> available extensions.
> Now is you working with a CPU that has AVX512
> extension, and in the case the compiler was setup to explicit assume that
> AVX512 is available and it is free to optimize using it, then the directive
> "x86_64_AVX512" would be defined in addition to "x86_64".
> And you don't have to define it for every single CPU configuration only
> major ones that people mostly use, or those that are petitioned because
> there are multiple compilers supporting it.
While I think you're right this should exist, I don't think it should be part
of the C++ Standard and thus need not be discussed here. What you need is to
get the group of compiler vendors to agree on something.
Which they already mostly do for x86 extensions at least: if you want AVX512,
__AVX512F__ is defined. If you want AVX10.2, you will get either __AVX10_2__ or
__AVX_VER__ depending on the compiler (because Microsoft decided to strike out
their own way). So yes, having a *written* list of predefined macros would
help, because you could then point to Microsoft not being compliant and just
not support them.
> That's the status quo right now, every single compiler has definitions to
> identify the architecture, but each have their own names for the same
> thing.
Yes, with a 90% overlap for macros and 99.9% overlap for the platform-specific
intrinsics.
> You don't just have to deal with the different architectures you
> may be targeting, you also need to know which possible compilers could be
> used and how they named those architectures. Make the name standard I don't
> need to worry about the compiler, I can just focus on the architecture.
Or you can choose the de facto standard and not support the compilers that
deviate from it, or only support basic functionality. Like MSVC.
Std-Discussion wrote:
> Ex. x86_64 could have the preprocessor directive "x86_64" no matter the
> available extensions.
> Now is you working with a CPU that has AVX512
> extension, and in the case the compiler was setup to explicit assume that
> AVX512 is available and it is free to optimize using it, then the directive
> "x86_64_AVX512" would be defined in addition to "x86_64".
> And you don't have to define it for every single CPU configuration only
> major ones that people mostly use, or those that are petitioned because
> there are multiple compilers supporting it.
While I think you're right this should exist, I don't think it should be part
of the C++ Standard and thus need not be discussed here. What you need is to
get the group of compiler vendors to agree on something.
Which they already mostly do for x86 extensions at least: if you want AVX512,
__AVX512F__ is defined. If you want AVX10.2, you will get either __AVX10_2__ or
__AVX_VER__ depending on the compiler (because Microsoft decided to strike out
their own way). So yes, having a *written* list of predefined macros would
help, because you could then point to Microsoft not being compliant and just
not support them.
> That's the status quo right now, every single compiler has definitions to
> identify the architecture, but each have their own names for the same
> thing.
Yes, with a 90% overlap for macros and 99.9% overlap for the platform-specific
intrinsics.
> You don't just have to deal with the different architectures you
> may be targeting, you also need to know which possible compilers could be
> used and how they named those architectures. Make the name standard I don't
> need to worry about the compiler, I can just focus on the architecture.
Or you can choose the de facto standard and not support the compilers that
deviate from it, or only support basic functionality. Like MSVC.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Platform & System Engineering
Received on 2025-08-30 20:45:27