On 27.08.2024 16:32, Andrew Cooper wrote: > On 27/08/2024 2:25 pm, Andrew Cooper wrote: >> On 27/08/2024 2:00 pm, Jan Beulich wrote: >>> On 27.08.2024 13:50, Andrew Cooper wrote: >>>> On 26/08/2024 12:55 pm, Jan Beulich wrote: >>>>> On 23.08.2024 01:06, Andrew Cooper wrote: >>>> Again, this is modelled after f[fl]s64() which have the same >>>> expectations about the BITS_PER_LONG != 64 case. >>> Both of them are fine afaict. fls64() has an explicit intermediate >>> variable of type uint32_t, and ffs64() has a (uint32_t)x as part >>> of the conditional expression achieving the intended effect. >>> >>> Anyway, why not use hweight32() instead of hweightl() here? That'll >>> make things very explicit. >> hweight32() doesn't exist until the next patch in the series. >> >> Although looking at the end result, I can't figure out why I thought it >> was necessary to transform hweight64 first. >> >> I'll swap this patch and the next one, and then use hweight32(). > > I've found out why. > > The hweight32() patch is the one that deletes generic_hweight32(), but > generic_hweight64() uses it. > > I can work around this, but it means keeping generic_hweight32() around > and deleting it in the hweight64() patch.
Or simply fold both patches? Jan
