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 ESMTPS id EA274385703C for ; Wed, 24 Aug 2022 09:49:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EA274385703C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661334566; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=X+LooGVBQugW6+jq3dsvAx3hRcyx909+L+FtI4qOYb8=; b=KJDBsMFBtPmsua3Pe84n+vc534llLW0E4NIfWPYAuDmh/9QVDeX25duO7xWdG3+N0DYqem aSIHMnHLv25T4fF/d+cB7YsfW+EJIe2L9XgLVW2BZB18KfeKzm2KTv2LVLH/E3aBRTAMS4 xckmWkg001H98tJXicM7NbfvlJxOQVA= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-258-7rq0PNl8Nm6I3H_AHp8o1w-1; Wed, 24 Aug 2022 05:49:23 -0400 X-MC-Unique: 7rq0PNl8Nm6I3H_AHp8o1w-1 Received: by mail-qk1-f200.google.com with SMTP id bp11-20020a05620a458b00b006bbeffab91dso9913778qkb.11 for ; Wed, 24 Aug 2022 02:49:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=X+LooGVBQugW6+jq3dsvAx3hRcyx909+L+FtI4qOYb8=; b=Rc1DnXWqyDQO592ibnvyes1mion0tIPk6hQwXKVId4T2BQ49ecWKuJ74/UVvXHCH8k KRKhniMq4djJJbQqJeicasV9kbv0aIJ6aVVa59BnbDB++SdSup8F9ayA7SR+Ilsjguzw i2LLx6OQHYIIbv8jo6YZD5IXEBxDWxkUSWM5CbJMo9spf5/AnNNubmZ68rNkBj9l1/JK nfjwIiis5uuiqLItVNMLEUuWA/FsP6S3cVB+ZsRYE4O+zbHJd/givyzkNx69WA33Q1Er tQQtc0Rsgu7tgJJG/JIXDgzUaHOK6yYCOUfVTZaE3W0akP5E77P4wHr7CDonN5vdYCws 01Gw== X-Gm-Message-State: ACgBeo2QfArEGvWQe5keTgT3JgMTdbn9npXTaaIOHYV92tYeovwWnoSw 37SEtKliM//k8ZW1UAd2Z5RcEFo+oo6sk06o8jpSJ3+qMNFOjLkuWm07HOGu362hmmDaq1u36Bf tmD9MWj2g/QsFNEpXXACB0MzQtwZBabs= X-Received: by 2002:ad4:5bc3:0:b0:482:5a89:c107 with SMTP id t3-20020ad45bc3000000b004825a89c107mr23539646qvt.84.1661334563425; Wed, 24 Aug 2022 02:49:23 -0700 (PDT) X-Google-Smtp-Source: AA6agR7bfJBFtxR2ZwzErEsLJliNL5CzRkEq8JBB/WWDY43p41bnrrHx1fAxlIf1T9W36Zq+u7buEiW18xIux9KSpIg= X-Received: by 2002:ad4:5bc3:0:b0:482:5a89:c107 with SMTP id t3-20020ad45bc3000000b004825a89c107mr23539636qvt.84.1661334563175; Wed, 24 Aug 2022 02:49:23 -0700 (PDT) MIME-Version: 1.0 References: <20220822181509.1032874-1-whh8b@obs.cr> <20220822181509.1032874-2-whh8b@obs.cr> In-Reply-To: From: Jonathan Wakely Date: Wed, 24 Aug 2022 10:49:12 +0100 Message-ID: Subject: Re: [PATCH] libstdc++: Optimize operator+(string/char*, string/char*) equally To: Will Hawkins Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 24 Aug 2022 at 07:18, Will Hawkins wrote: > > On Tue, Aug 23, 2022 at 12:33 PM Jonathan Wakely wrote: > > > > On Mon, 22 Aug 2022 at 19:15, Will Hawkins wrote: > > > > > > Until now operator+(char*, string) and operator+(string, char*) had > > > different performance characteristics. The former required a single > > > memory allocation and the latter required two. This patch makes the > > > performance equal. > > > > If you don't have a GCC copyright assignment on file with the FSF then > > please follow the procedure described at https://gcc.gnu.org/dco.html > > Thank you. > > > > > > > > libstdc++-v3/ChangeLog: > > > * libstdc++-v3/include/bits/basic_string.h (operator+(string, char*)): > > > Remove naive implementation. > > > * libstdc++-v3/include/bits/basic_string.tcc (operator+(string, char*)): > > > Add single-allocation implementation. > > > --- > > > libstdc++-v3/include/bits/basic_string.h | 7 +------ > > > libstdc++-v3/include/bits/basic_string.tcc | 21 +++++++++++++++++++++ > > > 2 files changed, 22 insertions(+), 6 deletions(-) > > > > > > diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h > > > index b04fba95678..bc048fc0689 100644 > > > --- a/libstdc++-v3/include/bits/basic_string.h > > > +++ b/libstdc++-v3/include/bits/basic_string.h > > > @@ -3523,12 +3523,7 @@ _GLIBCXX_END_NAMESPACE_CXX11 > > > _GLIBCXX20_CONSTEXPR > > > inline basic_string<_CharT, _Traits, _Alloc> > > > > Please remove the 'inline' specifier here, since you're moving the > > definition into the non-inline .tcc file. > > > > There's a separate discussion to be had about whether these operator+ > > overloads *should* be inline. But for the purposes of this change, we > > want these two operator+ overloads to be consistent, and so they > > should both be non-inline. > > Thank you for the feedback. I sent out a v2 of the patch. Again, I > hope that I followed the proper procedure by having my mailer put the > patch in reply to my previous message. It looks like the patch got attached in this thread, not the [PATCH v2] thread: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600176.html Presumably it was meant as a reply to: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600175.html It's more conventional to put the patch in the same email, not as a separate reply, which would avoid that problem. You can use git scissors to separate the patch submission from the preceding discussion and comments, see https://git-scm.com/docs/git-mailinfo#Documentation/git-mailinfo.txt---scissors For example, see my patches like the one at https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600109.html where the "informational" part comes first, describing where it was tested, then the patch (and its commit msg) come after the -- >8 -- scissors. If you use git send-email to send mails, you can use --in-reply-to=$MessageId to make the email a reply to the specified $MessageId from a previous mail in the thread. Anyway, the v2 patch looks fine and I'll apply it to trunk after testing - thanks!