On March 14, 2025 12:06:04 PM PDT, David Laight <david.laight.li...@gmail.com> wrote: >On Thu, 13 Mar 2025 14:09:24 -0700 >Jacob Keller <jacob.e.kel...@intel.com> wrote: > >> On 3/13/2025 9:36 AM, H. Peter Anvin wrote: >> > On March 13, 2025 9:24:38 AM PDT, Yury Norov <yury.no...@gmail.com> wrote: >> > >> >> On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote: >> >>> On March 12, 2025 4:56:31 PM PDT, Jacob Keller >> >>> <jacob.e.kel...@intel.com> wrote: >> >> >> >> [...] >> >> >> >>>> This is really a question of whether you expect odd or even parity as >> >>>> the "true" value. I think that would depend on context, and we may not >> >>>> reach a good consensus. >> >>>> >> >>>> I do agree that my brain would jump to "true is even, false is odd". >> >>>> However, I also agree returning the value as 0 for even and 1 for odd >> >>>> kind of made sense before, and updating this to be a bool and then >> >>>> requiring to switch all the callers is a bit obnoxious... >> >>> >> >>> Odd = 1 = true is the only same definition. It is a bitwise XOR, or sum >> >>> mod 1. >> >> >> >> The x86 implementation will be "popcnt(val) & 1", right? So if we >> >> choose to go with odd == false, we'll have to add an extra negation. >> >> So because it's a purely conventional thing, let's just pick a simpler >> >> one? >> >> >> >> Compiler's builtin parity() returns 1 for odd. >> >> >> >> Thanks, >> >> Yury >> > >> > The x86 implementation, no, but there will be plenty of others having that >> > exact definition. >> >> Makes sense to stick with that existing convention then. Enough to >> convince me. > >There is the possibility that the compiler will treat the builtin as having >an 'int' result without the constraint of it being zero or one. >In which case the conversion to bool will be a compare. >This doesn't happen on x86-64 (gcc or clang) - but who knows elsewhere. > >For x86 popcnt(val) & 1 is best (except for parity8) but requires a >non-archaic cpu. >(Probably Nehelem or K10 or later - includes Sandy bridge and all the 'earth >movers'.) >Since performance isn't critical the generic C code is actually ok. >(The 'parity' flag bit is only set on the low 8 bits.) > > David > >
You seem confused. We have already established that the built-in didn't currently produce good code on some cpus, but it does on others, with very little in between, so it would make sense to use the builtins on an opt-in basis. On x86 8- or 16-bit parity is best don't with test or xor respectively; 32- or 64-bit parity may use popcnt; test or by reducing down to a parity16 xor.
