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. ~Andrew
