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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
