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

Kristof Beyls via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Feb 29 00:59:44 PST 2020


kristof.beyls added a comment.

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

> In D74918#1897636 <https://reviews.llvm.org/D74918#1897636>, @kristof.beyls wrote:
>
> > 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?
>
>
> They will be in the library ABI, meaning the libc++ ABI.
>
> It's valid for libstdc++ and libc++ to have different values there. If we wish, we could try for an alignment (no pun intended) on these values, but even then that's just between these two libraries.
>
> Which is good and encouraging, because I don't know what forum we would have to go to.


I see.
So IIUC, this is library C++ ABI, to be defined by the C++ library. Since no 2 C++ libraries can co-exist in a single application, there is no need for different C++ libraries to agree?

I think there is still an issue then with getting the values of std::hardware_{constructive,destructive}_interference_size in the library implementation derived from compiler builtins.
There are quite a few systems where clang supports targeting a different C++ library than libc++, e.g. libstdc++ on linux or  (IIUC) the MSVC C++ library on Windows.
If these C++ libraries implement std::hardware_{constructive,destructive}_interference_size based on a value returned by a compiler builtin, and the different compilers that are used with these libraries return different values for such a builtin, then the library C++ ABI here will be dependent on which compiler used?
Doesn't this indicate that either:

- std::hardware_{constructive,destructive}_interference_size should not be implemented using a compiler builtin, or
- all compilers must return the same value for the builtin; for all targets they support.

Overall, that makes me doubt that using a compiler builtin to implement std::hardware_{constructive,destructive}_interference_size is the right direction.
If the functionality in this patch does not need to support implementing std::hardware_{constructive,destructive}_interference_size, then the design constraints for this patch change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74918





More information about the cfe-commits mailing list