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

[H. Peter Anvin]

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