At the “TBAA and extended floating-point types” topic I had hinted I had hinted at the possibility of having “standard extensions” that would only be available on certain architectures.

The idea being that these would allow to add content that for some reason or another is not feasible to implement in a common cross-platform way, but still provide important enough functionality that would be ice to standardize for different compilers targeting the same platform. Mostly low-level stuff.

1st pre-compiler directives for major cpu architectures should have a standard name. I.e. pre-compiler directives that tells you if you are emitting instructions for an Arm64, Risc-V, x86_64, etc…
Of course, compilers don’t have to know about directives that they don’t target, but if it targets a specific instruction set that the standard acknowledges the directive that identifies that is the same on all compilers targeting that architecture.

2nd All supported data types that make sense that makes sense to perform operations (or register types) should a well-defined type. No “unsigned int” or “float”, more of a “uint16”, “ieee_fp32”, or “AVX_512_fp64”

3rd All function that make sense on a specific architecture (things that the CPU provide specific instructions for) should be put in a library collection that is only available on a specific architecture being targeted.
Not necessarily every single instruction but most intrinsics should probably end-up there. I’m talking stuff like “cupid” (on arm or x86), AVX instructions, AES or CRC instructions.
The intel intrinsics library does a very good job to make this more or less portable, but I’m talking a similar thing for all major architectures. And if the functions do something deterministic, make it constexpr as well.

The point being that if I want to do something very specific, I don’t need to figure out how to abstract and implement it to work on every single architecture in order to get it into the standard.
A lot of stuff is important but doesn’t make sense everywhere.

Of course, using this feature would make your code not portable C++, and that is fine.
You can opt-in to it if that is what you really want, because sometimes it is fine that your code is made only to support only specific platforms.
And if there are specific thing that is only available on arm or x86, if that is only what you support, you can just pull those from the library and not have to re-invent the wheel.
Anything that is possible to do on a specific architecture, developers should have access to the building blocks and be allowed to express it in C++ (and build upon it).

Thoughts?