From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 6F546385743B for ; Sat, 17 Jul 2021 13:32:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F546385743B Received: by mail-wr1-x42c.google.com with SMTP id g16so15369493wrw.5 for ; Sat, 17 Jul 2021 06:32:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5X19Q/RxhGZVPO65f6d4JSh4avAM6y8zQ1gpl6uRBto=; b=IN6z0lA7bz4+alGcIiwLehC6P0o87HhN/bFBuZXg8ifBmHL/Hyz84luFNFHDeDFZGc ioedaQpjxS0P345Lka/dnYtcB0neu57w6UPWThvhA6i60H6DSdhtc6wY+7z2M9c7XPeQ l9BrD02hxRVETzZlhPZV4/KbXbo9Gy+PF3xDUw+3A4F6YQ7CgjDNfsnFCq/6FRfoJOrH ert7tT5u2Rxlr+ISWzkkLrKGpYy6mc8giKxcXMSQ4oeDv2iL57s4D9Hmvqzbw+aqEqsu I5fr/EW4yTVteUck1oc18LGqvwCCNiCb/UmKq4VE45v0zaafh73MuLKqfusT8SDuz+CQ CH8Q== X-Gm-Message-State: AOAM530Gc3YOYlidD3TlPKcwpcHsKhdg8erpbOzTV1pcKZ0SVxMKh+u8 KQf3lyhUujZh0mENFoeIFZ2EYQlKtyWei7C9wYs= X-Google-Smtp-Source: ABdhPJyAj2qMInEFwr2+l6Y9k9wSz5DuEj92U2s9+FKn1OPbaHW6vbwTAVJrAq/8Kx6v7JAPGUESWGSILxSxPw8xGH4= X-Received: by 2002:a5d:64c4:: with SMTP id f4mr19012971wri.21.1626528774610; Sat, 17 Jul 2021 06:32:54 -0700 (PDT) MIME-Version: 1.0 References: <20210716023656.670004-1-jason@redhat.com> <2948804.xd1mhZDcFd@excalibur> <3179041.TO5rdG3zkT@excalibur> In-Reply-To: <3179041.TO5rdG3zkT@excalibur> From: Jonathan Wakely Date: Sat, 17 Jul 2021 14:32:42 +0100 Message-ID: Subject: Re: [PATCH] c++: implement C++17 hardware interference size To: Matthias Kretz Cc: Jonathan Wakely , "Richard Earnshaw (lists)" , "libstdc++" , gcc-patches List , GNU C Library , Jason Merrill X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2021 13:32:57 -0000 On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote: > 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 > 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 > > > cat; > > > alignas(std::hardware_destructive_interference_size) std::atomic > > > 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 :-(