Re: [PATCH v4 00/13] Introduce parity_odd() and refactor redundant parity code

On 4/11/25 09:34, Kuan-Wei Chiu wrote:
>>
>> In either case, instead of packing the cascade into one function, make good
>> use of it.
>>
>> In the latter case, __builtin_constant_p() isn't necessary as it puts the
>> onus on the architecture to separate out const and non-const cases, if it
>> matters -- which it doesn't if the architecture simply wants to use
>> __builtin_parity:
>>
>> #define parity8(x)  ((bool) __builtin_parity((u8)(x)))
>> #define parity16(x) ((bool) __builtin_parity((u16)(x)))
>> #define parity32(x) ((bool) __builtin_parity((u32)(x)))
>> #define parity64(x) ((bool) __builtin_parityll((u64)(x)))
>>
>> As stated before, I don't really see that the parity function itself would
>> be very suitable for a generic helper, but if it were to, then using the
>> "standard" macro construct for it would seem to be the better option.
>>
>> (And I would be very much in favor of not open-coding the helper everywhere
>> but to macroize it; effectively creating a C++ template equivalent. It is
>> out of scope for this project, though.)
>>
> IIUC, you prefer using the parity8/16/32/64() interface with
> __builtin_parity(), regardless of whether there are users on the hot
> path?

As a per-architecture opt-in, yes.

	-hpa