Am Fr., 7. Feb. 2020 um 15:23 Uhr schrieb Jonathan Wakely <jwak...@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 > ><jwak...@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
