Re: [PATCH v3 01/16] bitops: Change parity8() return type to bool

On March 14, 2025 12:06:04 PM PDT, David Laight <[email protected]> wrote:
>On Thu, 13 Mar 2025 14:09:24 -0700
>Jacob Keller <[email protected]> wrote:
>
>> On 3/13/2025 9:36 AM, H. Peter Anvin wrote:
>> > On March 13, 2025 9:24:38 AM PDT, Yury Norov <[email protected]> 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 <[email protected]> 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.