[PATCH] D74918: Add method to TargetInfo to get CPU cache line size

[Kristof Beyls via Phabricator via cfe-commits]

kristof.beyls added a comment.

In D74918#1896930 <https://reviews.llvm.org/D74918#1896930>, @__simt__ wrote:

> (//I assume I'm not seeing a code review being used to veto a C++ Standard feature, but actually the other points are the reason for the red flag.//)
>
> I can see a desire for hyper-precise definitions to achieve the best possible performance, but we really need a healthy does of conservatism here.
>
> The C++ values can't change as a result of selecting between microarchitecture variations that are supposed to link, it takes an ABI break to change these.


If these values are part of the C++ target platform ABI, it seems to me the values for std::hardware_{constructive,destructive}_interference_size should be set by whoever has the authority to decide C++ platform ABI for specific platforms.
Assuming my thought in the previous sentence is correct; discussions on which values to chose for std::hardware_{constructive,destructive}_interference_size should happen in whichever forums decide C++ platform ABI for the various platforms? (Maybe for some platforms that forum might be clang-related fora like reviews.llvm.org, but probably not for all platforms).
With my (probably limited) understanding of the requirements, it seems like deriving std::hardware_{constructive,destructive}_interference_size from actual cache line size on a specific micro-architecture doesn't seem to be the right approach?

> We specified two numbers here so we could conservatively set them (e.g. constructive: smallest; destructive: largest) if we want, but then they are fixed.
> 
> I think there's just two plausible answers for x86_64:
> 
> 1. constructive=64, destructive=64 (the only plausible answer for X86 classic edition)
> 2. constructive=64, destructive=128 (reserve some room for line-pair designs)
> 
>   Recapping: precision is nice but we need to fix this in the ABI so ultimate precision isn't required nor desirable; we should choose one of these pairs (or debate if another pair is viable that I'm not thinking of); then we should ship C++17.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74918/new/

https://reviews.llvm.org/D74918