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

[Daniel Krügler]

Am Fr., 7. Feb. 2020 um 15:23 Uhr schrieb Jonathan Wakely <jwakely@redhat.com>:
>
> On 07/02/20 10:04 +0100, Daniel Krügler wrote:
> >Am Do., 6. Feb. 2020 um 15:28 Uhr schrieb Jonathan Wakely <jwakely@redhat.com>:
> >>
> >> 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.
> >
> >I like this suggestion.
>
> After discussing it with Jakub, I've decided to just use signed char.
>
> In theory int_fast8_t seems like the right choice, but it depends on
> how "fast" is interpreted. Fast for which operations? Is it actually
> going to be faster for the simple comparisons to constants and the
> bit masks that I use in <compare>?
>
> On a number of operating systems int_fast8_t is always int, even
> though byte accesses are no slower on many of the processors whre that
> OS runs.
>
> So we decided that unconditionally using a single byte will give us a
> small size and alignment, without sacrificing any performance.

Yes, I agree with your decision.

- Daniel