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
