Hi Yury, On Fri, Mar 07, 2025 at 10:55:13AM -0500, Yury Norov wrote: > On Fri, Mar 07, 2025 at 07:57:48AM +0100, Jiri Slaby wrote: > > On 06. 03. 25, 17:25, Kuan-Wei Chiu wrote: > > > Several parts of the kernel contain redundant implementations of parity > > > calculations for 16/32/64-bit values. Introduces generic > > > parity16/32/64() helpers in bitops.h, providing a standardized > > > and optimized implementation. > > > > > > Subsequent patches refactor various kernel components to replace > > > open-coded parity calculations with the new helpers, reducing code > > > duplication and improving maintainability. > > > > > > Co-developed-by: Yu-Chun Lin <eleanor15x@xxxxxxxxx> > > > Signed-off-by: Yu-Chun Lin <eleanor15x@xxxxxxxxx> > > > Signed-off-by: Kuan-Wei Chiu <visitorckw@xxxxxxxxx> > > > --- > > > In v3, I use parityXX() instead of the parity() macro since the > > > parity() macro may generate suboptimal code and requires special hacks > > > to make GCC happy. If anyone still prefers a single parity() macro, > > > please let me know. > > > > What is suboptimal and where exactly it matters? Have you actually measured > > it? > > I asked exactly this question at least 3 times, and have never > received perf tests or asm listings - nothing. I've never received > any comments from driver maintainers about how performance of the > parity() is important for them, as well. > To be clear, I use parityXX() was mainly because you dislike the >> 16 >> 16 hack, and I dislike the #if gcc #else hack—not due to performance or generated code considerations. > With the absence of _any_ feedback, I'm not going to take this series, > of course, for the reason: overengineering. > I'm quite surprised that three separate one-line functions are considered overengineering compared to a multi-line approach that requires special handling to satisfy gcc. > With that said, the simplest way would be replacing parity8(u8) with > parity(u64) 'one size fits all' thing. I even made a one extra step, > suggesting a macro that would generate a better code for smaller types > with almost no extra maintenance burden. This is another acceptable > option to me. > I'm fine with unifying everything to a single parity(u64) function. Before I submit the next version, please let me know if anyone has objections to this approach. Regards, Kuan-Wei
