Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper
Kuan-Wei Chiu <[email protected]>
| Newsgroups | dev.linux.lists.brcm80211,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-mtd,org.kernel.vger.bpf,org.kernel.vger.linux-input,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,org.kernel.vger.linux-serial,org.kernel.vger.linux-wireless,org.kernel.vger.netdev |
|---|---|
| Message-ID | <Z++cbTTp8leOJ5O+@visitorckw-System-Product-Name> |
Hi Jeremy, On Fri, Apr 04, 2025 at 10:51:55AM +0800, Jeremy Kerr wrote: > Hi Yuri & Kuan-Wei: > > > Thank you for sharing your opinion on this fixed parity(). Your > > arguments may or may not be important, depending on what existing > > users actually need. Unfortunately, Kuan-Wei didn't collect > > performance numbers and opinions from those proposed users. > > For the fsi-i2c side: this isn't a performance-critical path, and any > reasonable common approach would likely perform better that the current > per-bit implementation. > > Our common targets for this driver would be arm and powerpc64le. In case > it's useful as a reference, using the kernel compilers I have to hand, a > __builtin_parity() is a library call on the former, and a two-instruction > sequence for the latter. > Thanks for your feedback. IIUC, from the fsi-i2c perspective, parity efficiency isn't a major concern, but you still prefer optimizing with methods like __builtin_parity(). I'm just unsure if this aligns with Yury's point about needing "evidence that performance and/or code generation is important here." Regards, Kuna-Wei