[PATCH] libstdc++: Optimize C++20 comparison category types

[Jonathan Wakely]

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<=>(unspecified, weak_ordering)): Likewise.
>>	(strong_ordering::operator partial_ordering): Likewise.
>>	(strong_ordering::operator weak_ordering): Likewise.
>>	(operator<=>(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<std::partial_ordering, char> which would benefit.
>
>Anybody want to argue for or against making them 8 bits?
>
>