FR: Add cacheline size macros sufficient to support C++17 std::hardware_{con,de}structive_interference_size

[pkasting]

libc++ implements std::hardware_{con,de}structive_interference_size on gcc only due to clang lacking sufficient macro support. This bug requests that clang add sufficient support to implement this C++17ism in libc++.

[llvmbot]

@llvm/issue-subscribers-c-17

[ldionne]

Note that #83603 implements the library feature even on Clang, by hardcoding values per platform.

[h-vetinari]

Even if libcxx moves forward independently, copying an outline how to proceed for clang from the discourse thread on this:

@jyknight: While I still think this feature is not particularly useful, it is in the standard, and isn’t going to go away. So, I agree it would be appropriate to implement it – similarly to how GCC has implemented it.

This means:

• The compiler should define __GCC_DESTRUCTIVE_SIZE and __GCC_CONTRUCTIVE_SIZE values. These are explicitly non-stable, and should vary based on CPU tuning options passed to the compiler.

  When using a generic CPU, we probably want to set destructive to the maximum L1-cache-size of any “reasonably-popular” model in the family, and constructive to the minimum. If a particular CPU model tuning is set, we set both values to the L1-cache-size for that particular CPU model.

  The values we choose in Clang do not need to match to any other compiler’s implementation, nor any previous/future version of Clang. We may choose whichever values we believe will result in the best performance for users, and adjust as seems appropriate at any point in the future.

• There should be an on-by-default warning when using these values in a header or from within an exported interface of a module.

  That is, code like struct alignas(std::hardware_destructive_interference_size) X{} in a header should emit an on-by-default warning. GCC calls this diagnostic -Winterference-size. The purpose is to notify any potential user that it is (usually) inappropriate to use the values in way that is expected to be stable across multiple TUs – since it will vary depending on both compiler version and CPU tuning. This reduces the risk of implementing the feature substantially.

• We should allow the user to override the default values via explicit command-line option. GCC permits the user to specify -param=destructive-interference-size=NNN and -param=constructive-interference-size=NNN. I don’t know whether we should implement that same command-line interface, or if we should simply allow users to e.g. use -D__GCC_DESTRUCTIVE_SIZE=64 to override the default values, if they wish.

[pinskia]

itanium-cxx-abi/cxx-abi#74