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

[Louis Dionne via cfe-commits]

ldionne wrote:

> > > > For SystemZ the correct value is 256.
> > > 
> > > 
> > > Thanks! Double-checking: for both constructive and destructive?
> > 
> > 
> > Yes, for both. Every SystemZ model (supported by GCC/LLVM) has a L1 cache line size of 256 bytes.
> 
> Excellent, thank you!
> 
> > > > In general I agree it makes sense to look at the GCC implementation as a source of reasonable values. Also, I think there probably should be no generic default value at all - it there is no platform-specific value known, it seems better to not define those values rather than define them to some incorrect value ...
> > > 
> > > 
> > > On the one hand, I agree. But then libc++ will still have to pick default values to expose (these are `constexpr size_t` variables in libc++ rather than macros or `std::optional` values), so that just moves the problem elsewhere. Also, as best I can tell, that doesn't seem to be how GCC behaves (at least, from trying various GCC flavors on Compiler Explorer).
> > 
> > 
> > Looks like GCC's libstdc++ will simply not provide those variables either if GCC does not know those values for the current target:
> > ```
> > #ifdef __cpp_lib_hardware_interference_size // C++ >= 17 && defined(gcc_dest_sz)
> >   inline constexpr size_t hardware_destructive_interference_size = __GCC_DESTRUCTIVE_SIZE;
> >   inline constexpr size_t hardware_constructive_interference_size = __GCC_CONSTRUCTIVE_SIZE;
> > #endif // __cpp_lib_hardware_interference_size
> > ```
> 
> @ldionne do you have a preference? I can always skip defining the predefined macros unless a target has opted into providing that information.

Not defining these variables when we don't have a good value for them would make us non-conforming, so I agree with @cor3ntin : I think we should define these macros all the time and simply document that it's a best effort thing. This whole feature is a best effort thing anyways.


> I think it makes sense to go with this patch and let target maintainers tweak the value subsequently. It seems that trying to not provide a value unless explicitly specified by the target would be worse for library vendors as `hardware_destructive_interference_size` is specified to exist unconditionally.

Exactly. It's arguable whether this was a good decision on WG21's end or not, but it was specified as provided unconditionally by a conforming implementation, therefore that's what we need to do (IMO).

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