On 2021-07-17 06:32, Jonathan Wakely via Gcc-patches wrote:
On Sat, 17 Jul 2021, 09:15 Matthias Kretz, <m.kr...@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.kr...@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.
