From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 56CF73857C71 for ; Fri, 16 Jul 2021 18:44:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56CF73857C71 Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-m7-_9GR7NtS8--KM7IZC9w-1; Fri, 16 Jul 2021 14:44:02 -0400 X-MC-Unique: m7-_9GR7NtS8--KM7IZC9w-1 Received: by mail-pg1-f197.google.com with SMTP id j17-20020a63cf110000b0290226eb0c27acso7639947pgg.23 for ; Fri, 16 Jul 2021 11:44:02 -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=/a0h1foTI4kpYkka8x56uhsjARofmRBaecTZzNUiiMI=; b=jCBnHVf680YX39yHX8hSLyYS7sNmzI4A1o9+7vIMXA9mzYbVO3m6X1jdCz+f9Uwt9j 7vDshN9BDQjJbMcn3VirE5IhJkaMW+G0+TfXj5+fNyBECFamNU8UBuasKh9A5s5Gq6qy FanmQ/YIq4lXgHkWBcWvCkMCuJaCxKfy5t4hpyRgwp7OaCk90L+TaSEGhjZbldqHAeM+ eoLGAbK7sUuetDfW+rLEdPUoGlom/CfxJZchJZEsg6WoqflJxs87/RAhD2x89172ngRD EUbFjCP3rPWNX2c7A57GSedq5rkhW6cTPP5VfXpkDG2Bx1tgq6H2kC3yP/f3QI13SlMD WSpg== X-Gm-Message-State: AOAM530PCg8HiWK/Kw3JUIMemexzbdoYZUtWthehaBxBAIq78S9LrG+5 ZE8p/8pSQNLGI6hVZjM1dYBKPCs7vs6BhgSvRo/II8MEuR9zE43vO/ms1JD8HkpBVAvroNVj6YI PRDwcN05fS7bNmAMPsO36dZxBkvcn3M7aLCGt X-Received: by 2002:a17:903:1203:b029:12b:599b:524c with SMTP id l3-20020a1709031203b029012b599b524cmr6945109plh.10.1626461041496; Fri, 16 Jul 2021 11:44:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5+02badsIsp9xxMSF9J0r0/TUxp1RdG40K9ffiPN9llPkmD26IpxeEu1yQlYJcYh8BuvG1XCyz4ZkYIzmGn8= X-Received: by 2002:a17:903:1203:b029:12b:599b:524c with SMTP id l3-20020a1709031203b029012b599b524cmr6945085plh.10.1626461041092; Fri, 16 Jul 2021 11:44:01 -0700 (PDT) MIME-Version: 1.0 References: <20210716023656.670004-1-jason@redhat.com> <2136759.qKCeTcHjAi@excalibur> In-Reply-To: From: Jason Merrill Date: Fri, 16 Jul 2021 14:43:48 -0400 Message-ID: Subject: Re: [PATCH] c++: implement C++17 hardware interference size To: Jonathan Wakely Cc: Matthias Kretz , "Richard Earnshaw (lists)" , "libstdc++" , gcc-patches List , GNU C Library X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable 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: Fri, 16 Jul 2021 18:44:07 -0000 On Fri, Jul 16, 2021, 12:54 PM 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? > Absolutely, though with the below warning, which could mention this issue, it would only affect the ABI of code that ignores the warning. Code that silences it by specifying values would not be affected. > I'm thinking about warning by default for any use of the variables without > > explicitly specifying their values on the command line. Users could > disable > > the warning if they're happy using whatever the defaults happen to be. > > I like that suggestion. > > Maybe the warning could suggest optimal values based on the current > -mtune flag. Sounds good. That way -mtune wouldn't need to alter ABI, but by > combining -mtune with explicit values for the variables you get the > best performance. And -mtune without overriding the default values > preserves ABI. > >