On Fri, Apr 25, 2025 at 12:33:21PM -0700, H. Peter Anvin wrote: > 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. > I'd prefer to see Yury agree first, otherwise there's a high risk of a maintainer NAK after the next submission. Regards, Kuan-Wei
