From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35256 invoked by alias); 6 Feb 2020 14:28:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 35173 invoked by uid 89); 6 Feb 2020 14:28:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Feb 2020 14:28:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580999301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fJkJSMfCd+qwpk9ndW8wYAeK8d3cW56VtJ/0PzBEgTs=; b=A5am47826zI76T004k2fakvDoZMJqSPgRVDl3Zup8XxWslB9n3xLq4KlekOKCWJwhjQpKm z+Sw54gyb/JrL0Lk7wNAMRrF+M/c6OVCaonjqdE1PZyVm7+6AkY7sgwQ4YF/CMSUid+pXY amjxp/f3YGha2JC8HtFfMT8X4lAXXbg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-78-51iFlSMaMZ-ZDBMXvlvzuQ-1; Thu, 06 Feb 2020 09:28:19 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5F19D800D5F; Thu, 6 Feb 2020 14:28:18 +0000 (UTC) Received: from localhost (unknown [10.33.36.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0E80F859D2; Thu, 6 Feb 2020 14:28:17 +0000 (UTC) Date: Thu, 06 Feb 2020 14:28:00 -0000 From: Jonathan Wakely To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] libstdc++: Optimize C++20 comparison category types Message-ID: <20200206142817.GB946869@redhat.com> References: <20200206134048.GA946321@redhat.com> <20200206135356.GA946869@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200206135356.GA946869@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2020-02/txt/msg00366.txt.bz2 On 06/02/20 13:53 +0000, Jonathan Wakely wrote: >On 06/02/20 13:40 +0000, Jonathan Wakely wrote: >>This reduces sizeof(std::partial_ordering) and optimizes conversion and >>comparison operators to avoid conditional branches where possible. >> >> * libsupc++/compare (__cmp_cat::_Ncmp::unordered): Change value to 2. >> (partial_ordering::_M_is_ordered): Remove data member. >> (partial_ordering): Use second bit of _M_value for unordered. Adjust >> comparison operators. >> (weak_ordering::operator partial_ordering): Simplify to remove >> branches. >> (operator<=3D>(unspecified, weak_ordering)): Likewise. >> (strong_ordering::operator partial_ordering): Likewise. >> (strong_ordering::operator weak_ordering): Likewise. >> (operator<=3D>(unspecified, strong_ordering)): Likewise. >> * testsuite/18_support/comparisons/categories/partialord.cc: New test. >> * testsuite/18_support/comparisons/categories/strongord.cc: New test. >> * testsuite/18_support/comparisons/categories/weakord.cc: New test. >> >>Tested powerpc64le-linux and x86_64-linux. >> >>This is an ABI change for the partial_ordering type, but that is why I >>think we should do it now, not after GCC 10 is released. The sooner >>the better, before these types are being widely used. >> >>I plan to commit this in the next 12 hours or so, unless there are >>(valid :-) objections. >> >>Thanks to Barry Revzin for pointing out there was room for these >>operators to be improved. > >We could also change the int _M_value data member of all three >comparison category types to be a signed char instead of int. That >would reduce the size further. Or maybe std::int_fast8_t is the right type here. >It probably doesn't matter for most uses, only when one of the types >is used as a data member and the smaller type would allow a more >compact layout. I'm not sure how common such uses will be, but I >suppose it's plausible somebody could have a function returning a >std::tuple which would benefit. > >Anybody want to argue for or against making them 8 bits? > >