From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lxmtout1.gsi.de (lxmtout1.gsi.de [140.181.3.111]) by sourceware.org (Postfix) with ESMTPS id D28A1385380F; Sat, 17 Jul 2021 08:14:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D28A1385380F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gsi.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gsi.de Received: from localhost (localhost [127.0.0.1]) by lxmtout1.gsi.de (Postfix) with ESMTP id 4614D2050D12; Sat, 17 Jul 2021 10:14:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lxmtout1.gsi.de Received: from lxmtout1.gsi.de ([127.0.0.1]) by localhost (lxmtout1.gsi.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hiT9zoPm69m2; Sat, 17 Jul 2021 10:14:51 +0200 (CEST) Received: from srvex1.campus.gsi.de (unknown [10.10.4.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by lxmtout1.gsi.de (Postfix) with ESMTPS id 285DC2050D10; Sat, 17 Jul 2021 10:14:51 +0200 (CEST) Received: from excalibur.localnet (140.181.3.12) by srvex1.campus.gsi.de (10.10.4.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.10; Sat, 17 Jul 2021 10:14:50 +0200 From: Matthias Kretz To: Jonathan Wakely CC: Jason Merrill , "Richard Earnshaw (lists)" , libstdc++ , gcc-patches List , GNU C Library Subject: Re: [PATCH] c++: implement C++17 hardware interference size Date: Sat, 17 Jul 2021 10:14:50 +0200 Message-ID: <3179041.TO5rdG3zkT@excalibur> Organization: GSI Helmholtzzentrum =?UTF-8?B?ZsO8cg==?= Schwerionenforschung In-Reply-To: References: <20210716023656.670004-1-jason@redhat.com> <2948804.xd1mhZDcFd@excalibur> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [140.181.3.12] X-ClientProxiedBy: srvex1.Campus.gsi.de (10.10.4.11) To srvex1.campus.gsi.de (10.10.4.11) X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2021 08:14:55 -0000 On Friday, 16 July 2021 21:58:36 CEST Jonathan Wakely wrote: > On Fri, 16 Jul 2021 at 20:26, Matthias Kretz 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 significa= nt > > > > use > > > > case, perhaps the only reasonable use. Cases more concerned with A= BI > > > > stability probably shouldn't use them at all. And that would mean n= ot > > > > needing to worry about the impossible task of finding the right val= ues > > > > for > > > > an entire architecture. > > >=20 > > > But it would be quite a significant change in behaviour if -mtune > > > started affecting ABI, wouldn't it? > >=20 > > For existing code -mtune still doesn't affect ABI. >=20 > True, because existing code isn't using the constants. >=20 > >The users who write > > > > struct keep_apart { > >=20 > > alignas(std::hardware_destructive_interference_size) std::atomic > > cat; > > alignas(std::hardware_destructive_interference_size) std::atomic > > dog; > >=20 > > }; > >=20 > > *want* to have different sizeof(keep_apart) depending on the CPU the co= de > > is compiled for. I.e. they *ask* for getting their ABI broken. >=20 > 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= =20 compiling the code can change the data layout of keep_apart via -mtune. Of= =20 course, if the one compiling doesn't want to choose because the binary need= s=20 to work on the widest range of systems, then there's a problem we might wan= t=20 to solve (direction of target_clones?). (Or the developer of the library=20 solves it by providing the ABI for all possible interference_size values.) > A distro might add -mtune=3Dcore2 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=20 you're right. > 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= =20 flags is UB. In general I think that's correct, but we can make explicit=20 exceptions. Up to now -mtune wouldn't lead to UB, AFAIK, though -march easi= ly=20 does. So maybe, to keep the status quo, the constants should be tied to -ma= rch=20 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 abo= ut=20 binary distribution. If his code has an ABI issue, that's a bug he needs to= =20 fix. It's not the fault of the packager. =2D-=20 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de std::experimental::simd https://github.com/VcDevel/std-simd =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80