[clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

[Aaron Ballman via cfe-commits]

================
@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those languages.
 C++ Language Changes
 --------------------
 
+C++17 Feature Support
+^^^^^^^^^^^^^^^^^^^^^
+- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE``
+  predefined macros to support standard library implementations of
+  ``std::hardware_destructive_interference_size`` and
+  ``std::hardware_constructive_interference_size``, respectively. These macros
+  are predefined in all C and C++ language modes. These macros can be
+  overridden on the command line with ``-D``, if desired. The values the macros
----------------
AaronBallman wrote:

> There should to be a user-facing way to set this, in order to pin it to a particular value. If not -D, then e.g. copy GCC's `--param hardware_destructive_interference_size=N` command-line.

`-D` is my preference, mostly because `--param` is not something we already support for options. I could put something into the extensions documentation to mention this?

> How do they know that this constant is not ABI-stable, unlike the entire rest of the library?

I would assume that anyone using this interface is aware of the fact that it's tightly coupled with the CPU tuning used by the program and I would hope that folks are compiling with sanitizers enabled so they'd catch ABI issues more broadly than just this one narrow case. At the same time, defense in depth is not a bad thing.

> That may not be ideal, but it's a relatively simple solution that seems likely to be good enough. I think Clang could quite reasonably do the same thing.

I'll take a run at implementing that; it feels a bit user hostile because there are benign uses within a header file and the macro is exposed in C while the STL interface isn't, but it does provide *some* measure of protection.

https://github.com/llvm/llvm-project/pull/89446