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_SIZEand__GCC_CONTRUCTIVE_SIZEvalues. 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=NNNand-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=64to override the default values, if they wish.