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.129.124]) by sourceware.org (Postfix) with ESMTPS id E7FE13858415 for ; Tue, 23 Aug 2022 13:44:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7FE13858415 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-517-so2e6NmzMqaJihqVTO9Z_A-1; Tue, 23 Aug 2022 09:44:37 -0400 X-MC-Unique: so2e6NmzMqaJihqVTO9Z_A-1 Received: by mail-qt1-f200.google.com with SMTP id bz20-20020a05622a1e9400b003436a76c6e6so10507265qtb.1 for ; Tue, 23 Aug 2022 06:44:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc; bh=MItXlmFaDsf2kHUb/RAis/YF25BD6asbg2f75P1lUdY=; b=1phaiGvZP7fOyiklbz0vmFz0E69i9pbnn5xzVxrJkipn3Jpzwl0QSU6ldYMktx4L9Y GmhMU9Fn9/99mhc608s8QsGz6K0VJqoYXJDyYwL6ogD128xyuB0MNI6j8T3fPxWidi3j zlzUpPcBkHgD1zZ/w7FiOM9mixtfG9asC1BFQY8dJaxFAq+KZx6ioby+bd+tXq1L2gyj 24vgL+aHpCONe3wBCv8ds8/0nHNvxJo3WzyQ1IRuYsSNDGCRmmDeaMjJJZxtSUJqxtJ7 4WsrYEN2EOGOaSvgflwVwGr8wibks0ny+G7dPKVwQBrzEgg4Lw/JkffyFz7Vq8/r6eFU 2Iag== X-Gm-Message-State: ACgBeo0F8pgxvOqU2hqolkWi8VWjVX1EGC/Y7SG0K70jX8e+G8HCFikG DSnvVVLDNrpVjRvazah3XL8dZNyHs26Tc2ymIOOYO00/3e3G+RWH5vkPHjPIAFqeqaitKbl4Uws 2nnzhpajJAv6XWDFwxg== X-Received: by 2002:ad4:5ecb:0:b0:474:7449:e897 with SMTP id jm11-20020ad45ecb000000b004747449e897mr19451195qvb.112.1661262276852; Tue, 23 Aug 2022 06:44:36 -0700 (PDT) X-Google-Smtp-Source: AA6agR4fC2YJZic65aeERlE9QIFNhFYQ4SKmjbx8jA2PUMiuTcLiE1JFpaNnaSOdRDH/UTUFGACFJg== X-Received: by 2002:ad4:5ecb:0:b0:474:7449:e897 with SMTP id jm11-20020ad45ecb000000b004747449e897mr19451175qvb.112.1661262276610; Tue, 23 Aug 2022 06:44:36 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id a18-20020ac844b2000000b0031ef69c9024sm10534347qto.91.2022.08.23.06.44.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Aug 2022 06:44:36 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Tue, 23 Aug 2022 09:44:35 -0400 (EDT) To: Jonathan Wakely cc: Patrick Palka , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH 1/3] libstdc++: Separate construct/convertibility tests for std::tuple In-Reply-To: Message-ID: <6f6c8fa3-26b0-cf5f-0926-7c2dab46b63a@idea> References: <20220823013500.1756466-1-ppalka@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-14.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2022 13:44:40 -0000 On Tue, 23 Aug 2022, Jonathan Wakely wrote: > On Tue, 23 Aug 2022 at 02:35, Patrick Palka via Libstdc++ > wrote: > > > > P2321R2 adds new conditionally explicit constructors to std::tuple which > > we'll concisely implement in a subsequent patch using explicit(bool), like > > in our C++20 std::pair implementation. But before we can do that, this > > patch first adds members to _TupleConstraints that test for constructibility > > and convertibility separately; we'll use the first in the new constructors' > > constraints, and the second in their explicit specifier. > > > > In passing, this patch also redefines the existing predicates > > __is_ex/implicitly_constructible in terms of these new members. This > > seems to reduce compile time and memory usage by about 10% for large > > Nice. > > > tuples when using the relevant constructors constrained by > > _Explicit/_ImplicitCtor (since we no longer have to redundantly expand > > and process is_constructible<_Types, _UTypes>... twice for each pair of > > such constructors). In order to retain maximal short circuiting, do > > this only when constexpr if is available. > > Would we get similar benefits for C++11 and C++14 by doing: > > return __and_<__and_...>, > __and_...> > >::value; > > This is slightly more work in total, but if we have __and_ and > __and_> then the A and B instantiations will be cached and > can be reused. Good idea, it seems we get pretty much the same 10% improvement for C++11/14 with this approach. I reckon we might as well then define __convertible and __constructible as alias templates instead of as variable templates and use them unconditionally in __is_im/explicitly_constructible for benefit of all language versions. Using constexpr if instead of the outer __and_ seems to yield a marginal improvement at best and __and_v is currently just __and_::value, so it doesn't seem worth it to have different definitions for C++17 at least for now. What do you think about the following? -- >8 -- libstdc++-v3/ChangeLog: * include/std/tuple (_TupleConstraints::__convertible): Define. (_TupleConstraints::__constructible): Likewise. (_TupleConstraints::__is_explicitly_constructible): Redefine this in terms of __convertible and __constructible. (_TupleConstraints::__is_implicitly_constructible): Likewise. --- libstdc++-v3/include/std/tuple | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple index 6d0060a191c..f8f48ccc370 100644 --- a/libstdc++-v3/include/std/tuple +++ b/libstdc++-v3/include/std/tuple @@ -553,15 +553,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template struct _TupleConstraints { + template + using __constructible = __and_...>; + + template + using __convertible = __and_...>; + // Constraint for a non-explicit constructor. // True iff each Ti in _Types... can be constructed from Ui in _UTypes... // and every Ui is implicitly convertible to Ti. template static constexpr bool __is_implicitly_constructible() { - return __and_..., - is_convertible<_UTypes, _Types>... - >::value; + return __and_<__constructible<_UTypes...>, + __convertible<_UTypes...>>::value; } // Constraint for a non-explicit constructor. @@ -570,9 +575,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template static constexpr bool __is_explicitly_constructible() { - return __and_..., - __not_<__and_...>> - >::value; + return __and_<__constructible<_UTypes...>, + __not_<__convertible<_UTypes...>>>::value; } static constexpr bool __is_implicitly_default_constructible() -- 2.37.2.382.g795ea8776b