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 A4D753861C5E for ; Fri, 16 Jul 2021 18:44:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A4D753861C5E Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-362-zruk3FG4M5aPgIjoYMOI7A-1; Fri, 16 Jul 2021 14:44:02 -0400 X-MC-Unique: zruk3FG4M5aPgIjoYMOI7A-1 Received: by mail-pj1-f71.google.com with SMTP id u12-20020a17090abb0cb029016ee12ec9a1so5950066pjr.3 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=sOsy21xsg/Ll+XHsiL1bbE06AiJCeJPQGZemK+TdcZBBbIm0I3fZEtAlzNow6NVebW XN+o19rNB/gZ08I7d/XrnbjpIB14ELhs47uJqg+NW5+zvQoX75XcHqape7JcCjFR+KXZ 0IxCiSPmlE8fmFQEa2YoFpx19EwpxwCWdl4oOagoimtk+UqMQs3dfoORpeWSphfuSUd8 qmm8Izbiuh2tLfKlIuT0U6z4Wsgody9jlG9e+5oBOOVo807R7PE0ILIhrfDC+8UbeASz 9lvy6Fj9Sh64WzvQnIZcqnNmlSvP47Yr7lx3o3TYvSXzIk8GwghqUAb3DVSvYZ86Z/4x Ra5g== X-Gm-Message-State: AOAM531d1GcLc+EciJ0pTwM6M+Vqh3UcHhbHFaTMh66st6T0V/AIFUFa wX5VFqzkaI5jiTqiSktjYVRVJ9pjmlISSH+vqhna6JhuxAP0/NYJZJ0KSBmyDAp83edc7NWAJY+ 3ZWM7ITsqbzIz1lU7eSoOb9GAKnyUkxM= X-Received: by 2002:a17:903:1203:b029:12b:599b:524c with SMTP id l3-20020a1709031203b029012b599b524cmr6945114plh.10.1626461041498; 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=-4.7 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: 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: Fri, 16 Jul 2021 18:44:05 -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. > >