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 B221A3858C83 for ; Tue, 23 Aug 2022 01:35:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B221A3858C83 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-418-lO89l-BdN_SQqwy8tedYtQ-1; Mon, 22 Aug 2022 21:35:04 -0400 X-MC-Unique: lO89l-BdN_SQqwy8tedYtQ-1 Received: by mail-qv1-f69.google.com with SMTP id lj8-20020a0562145c8800b00496ceb190d4so3440300qvb.3 for ; Mon, 22 Aug 2022 18:35:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc; bh=xwJga+iKr7YMPjR2NLqP6/50JDlQiXx2+7MRt68EoOY=; b=KC+mlUnPYkxjwt+f0CvxQJOeRUMZ3Ck2XVX2YhVBGVi323o6yke+95X58jC+EzBbtb Ra2c8mHV4BALWbbAKKYJ8sl8D2uEogNr8iWBZTO08bedZ6gggukc2Bw+CLCPBClj/GxE mS3RipbMhCQIdIOOd5L3vbNU9mLzNIHoiTyuLw5QFDvlye8zBAiq+8nStB/RaEcBQvMN TXC2arl7N5nFHyrwTPZxFJOTcCFRCba1hU7/8OdEBLW00HRstRA+mLDWGeiLOtpLHGUy 4yud4V/Yi2dy++Sr3JrtgVrBJO1t6YGPT7rlsQTPacJXkKrYp4cyjb3fzGD2qcVJKR1u YT4w== X-Gm-Message-State: ACgBeo2FhtOYvboA3v1ZvQ3L1vIJEFBGjUR8baRg6BuKArJiz48G8pvs +SQAqCsLGUk4o/EoqiAuOgYQSXUksnKAODvY2hktZnFDgnETdo2giXFiDttH1Siv7fm945JyrKN 8Y2tAWXZM3CKWfj0= X-Received: by 2002:a05:622a:3d0:b0:343:58db:d5c7 with SMTP id k16-20020a05622a03d000b0034358dbd5c7mr17364579qtx.21.1661218503642; Mon, 22 Aug 2022 18:35:03 -0700 (PDT) X-Google-Smtp-Source: AA6agR6TlkUp5UmnZ762nbQE4d8TK7rdzKGtjGHhpqfB5VOEXQ7WAdf4e5Pz7wHiM4dfkxSq40S5Sw== X-Received: by 2002:a05:622a:3d0:b0:343:58db:d5c7 with SMTP id k16-20020a05622a03d000b0034358dbd5c7mr17364566qtx.21.1661218503403; Mon, 22 Aug 2022 18:35:03 -0700 (PDT) Received: from localhost.localdomain (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id p11-20020ac8740b000000b00342fcdc2d46sm9816942qtq.56.2022.08.22.18.35.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Aug 2022 18:35:03 -0700 (PDT) From: Patrick Palka To: gcc-patches@gcc.gnu.org Cc: libstdc++@gcc.gnu.org, Patrick Palka Subject: [PATCH 1/3] libstdc++: Separate construct/convertibility tests for std::tuple Date: Mon, 22 Aug 2022 21:34:58 -0400 Message-Id: <20220823013500.1756466-1-ppalka@redhat.com> X-Mailer: git-send-email 2.37.2.382.g795ea8776b MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-14.0 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_NONE, 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: 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: Tue, 23 Aug 2022 01:35:07 -0000 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 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. Tested on x86_64-pc-linux-gnu, does this look OK for trunk? libstdc++-v3/ChangeLog: * include/std/tuple (_TupleConstraints::__convertible): Define for C++17. (_TupleConstraints::__constructible): Likewise. (_TupleConstraints::__is_explicitly_constructible): For C++17 define this in terms of __convertible and __constructible using constexpr if. (_TupleConstraints::__is_implicitly_constructible): Likewise. --- libstdc++-v3/include/std/tuple | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple index 6d0060a191c..d0c168fd7e2 100644 --- a/libstdc++-v3/include/std/tuple +++ b/libstdc++-v3/include/std/tuple @@ -553,15 +553,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template struct _TupleConstraints { +#if __cplusplus >= 201703L + template + static constexpr bool __constructible + = __and_v...>; + + template + static constexpr bool __convertible + = __and_v...>; +#endif + // 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() { +#if __cplusplus >= 201703L + if constexpr (__constructible<_UTypes...>) + return __convertible<_UTypes...>; + return false; +#else return __and_..., is_convertible<_UTypes, _Types>... >::value; +#endif } // Constraint for a non-explicit constructor. @@ -570,9 +586,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template static constexpr bool __is_explicitly_constructible() { +#if __cplusplus >= 201703L + if constexpr (__constructible<_UTypes...>) + return !__convertible<_UTypes...>; + return false; +#else return __and_..., __not_<__and_...>> >::value; +#endif } static constexpr bool __is_implicitly_default_constructible() -- 2.37.2.382.g795ea8776b