On 26/06/2024 11:17 am, Jan Beulich wrote: > On 25.06.2024 21:07, Andrew Cooper wrote: >> The prior version (renamed to bitmap_for_each()) was inefficeint when used >> over a scalar, but this is the more common usage even before accounting for >> the many opencoded forms. >> >> Introduce a new version which operates on scalars only and does so without >> spilling them to memory. This in turn requires the addition of a >> type-generic >> form of ffs(). >> >> Add testing for the new construct alongside the ffs/fls testing. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Reviewed-by: Jan Beulich <jbeul...@suse.com>
Thanks. > with two remarks: > >> The naming of ffs_g() is taken from the new compiler builtins which are using >> a g suffix to mean type-generic. > As you say, a g suffix, not a _g one; gcc14 documents __builtin_ffsg(). > (Seeing it exists I wonder whether we wouldn't want to use it when > available, and only fall back to the macro for older versions.) Any > specific reason you use _g? Legibility. It's bad enough with the l() and ll() forms (which get worse with the hweight() series, and I can't find a nice option). The other option I considered was have ffs() be the generic one, and have ffsi() for the int variant, but now we're in active contradiction with the builtin scheme, rather than merely opting not to use it. I don't expect this to get much use in practice. Use of this in regular code mixing ints and longs is almost certainly a bug on behalf of the programmer. ~Andrew
