[PATCH] c++: implement C++17 hardware interference size

[Thomas Rodgers]

On 2021-07-17 06:32, Jonathan Wakely via Gcc-patches wrote:

> On Sat, 17 Jul 2021, 09:15 Matthias Kretz, <m.kretz@gsi.de> wrote:
> 
> On Friday, 16 July 2021 21:58:36 CEST Jonathan Wakely wrote: On Fri, 16 
> Jul 2021 at 20:26, Matthias Kretz <m.kretz@gsi.de> wrote: On Friday, 16 
> July 2021 18:54:30 CEST Jonathan Wakely wrote: On Fri, 16 Jul 2021 at 
> 16:33, Jason Merrill wrote: Adjusting them based on tuning would 
> certainly simplify a
  significant

> use
> case, perhaps the only reasonable use.  Cases more concerned with
  ABI

> stability probably shouldn't use them at all. And that would mean
  not

> needing to worry about the impossible task of finding the right
  values

> for
> an entire architecture.
> But it would be quite a significant change in behaviour if -mtune
> started affecting ABI, wouldn't it?

For existing code -mtune still doesn't affect ABI.
True, because existing code isn't using the constants.

> The users who write
> 
> struct keep_apart {
> 
> alignas(std::hardware_destructive_interference_size) std::atomic<int>
> cat;
> alignas(std::hardware_destructive_interference_size) std::atomic<int>
> dog;
> 
> };
> 
> *want* to have different sizeof(keep_apart) depending on the CPU the
  code

>> is compiled for. I.e. they *ask* for getting their ABI broken.
> 
> Right, but the person who wants that and the person who chooses the
> -mtune option might be different people.

Yes. But it was the intent of the person who wrote the code that the
person
compiling the code can change the data layout of keep_apart via -mtune. 
Of
course, if the one compiling doesn't want to choose because the binary
needs
to work on the widest range of systems, then there's a problem we might
want
to solve (direction of target_clones?). (Or the developer of the library
solves it by providing the ABI for all possible interference_size 
values.)

> A distro might add -mtune=core2 to all package builds by default, not
> expecting it to cause ABI changes. Some header in a package in the
> distro might start using the constants. Now everybody who includes
> that header needs to use the same -mtune option as the distro default.

If somebody writes a library with `keep_apart` in the public API/ABI 
then
you're right.

Yes, it's fine if those constants don't affect anything across module
boundaries.

>> That change in the behaviour and expected use of an existing option
>> seems scary to me. Even with a warning about using the constants
>> (because somebody's just going to use #pragma around their use of the
>> constants to disable the warning, and now the ABI impact of -mtune is
>> much less obvious).
> 
> There are people who say that linking TUs compiled with different 
> compiler
> flags is UB. In general I think that's correct, but we can make 
> explicit
> exceptions. Up to now -mtune wouldn't lead to UB, AFAIK, though -march
> easily
> does. So maybe, to keep the status quo, the constants should be tied to
> -march
> not -mtune?
> 
>> It's much less scary in a world where the code is written and used by
>> the same group of people, but for something like a linux distro it
>> worries me.
> 
> The developer who wants his code to be included in a distro should care
> about
> binary distribution. If his code has an ABI issue, that's a bug he 
> needs
> to
> fix. It's not the fault of the packager.

Yes but in practice it's the packagers who have to deal with the bug
reports, analyze the problem, and often fix the bug too. It might not be
the packager's fault but it's often their problem :-(

Apropos of nothing, I can absolutely see the use of this creeping into 
Boost at some point.