On Mon, Jun 09, 2025 at 11:45:44AM +0900, Vincent Mailhol via B4 Relay wrote: > This is a subset of below series: > > bits: Fixed-type GENMASK_U*() and BIT_U*() > Link: > https://lore.kernel.org/r/20250308-fixed-type-genmasks-v6-0-f59315e73...@wanadoo.fr > > Yury suggested to split the above series in two steps: > > #1 Introduce the new fixed type GENMASK_U*() (already merged upstream) > #2 Consolidate the existing GENMASK*() > > This new series is the resulting step #2 following the split. > > And thus, this series consolidate all the non-asm GENMASK*() so that > they now all depend on GENMASK_TYPE() which was introduced in step #1. > > To do so, I had to split the definition of the asm and non-asm > GENMASK(). I think this is controversial. So I initially implemented a > first draft in which both the asm and non-asm version would rely on > the same helper macro, i.e. adding this: > > #define __GENMASK_TYPE(t, w, h, l) \ > (((t)~_ULL(0) << (l)) & \ > ((t)~_ULL(0) >> (w - 1 - (h)))) > > to uapi/bits.h. And then, the different GENMASK()s would look like > this: > > #define __GENMASK(h, l) __GENMASK_TYPE(unsigned long, __BITS_PER_LONG, h, l) > > and so on. > > I implemented it, and the final result looked quite ugly. Not only do > we need to manually provide the width each time, the biggest concern > is that adding this to the uapi is asking for trouble. Who knows how > people are going to use this? And once it is in the uapi, there is > virtually no way back. > > Adding to this, that macro can not even be generalised to u128 > integers, whereas after the split, it can. > > And so, after implementing both, the asm seems way cleaner than the > non-asm split and is, I think, the best compromise. > > Aside from the split, the asm's GENMASK() and GENMASK_ULL() are left > untouched. While there are some strong incentives to also simplify > these as pointed by David Laight in this thread: > > https://lore.kernel.org/all/20250309102312.4ff08576@pumpkin/ > > this series deliberately limit its scope to the non-asm variants. > > Here are the bloat-o-meter stats: > > $ ./scripts/bloat-o-meter vmlinux_before.o vmlinux_after.o > add/remove: 0/0 grow/shrink: 4/2 up/down: 5/-9 (-4) > Function old new delta > intel_psr_invalidate 352 354 +2 > mst_stream_compute_config 1589 1590 +1 > intel_psr_flush 707 708 +1 > intel_dp_compute_link_config 1338 1339 +1 > intel_drrs_activate 398 395 -3 > cfg80211_inform_bss_data 5137 5131 -6 > Total: Before=23333846, After=23333842, chg -0.00% > > (done with GCC 12.4.1 on an x86_64 defconfig)
So, I'm still concerned about that split for C and asm implementations. But seemingly nobody else does, and after all it's a nice consolidation. I've moved this in bitmap-for-next for testing. Thank you Vincent for your work. Thanks, Yury
