On Wed, May 17, 2023 at 11:06:56AM +0100, Richard W.M. Jones wrote:
It takes a 64 bit integer and finds the next power of 2, eg. next_power_of_2 (510) => 512 (2^9)
Taken from https://jameshfisher.com/2018/03/30/round-up-power-2/ with some fixes.
Thanks: Eric Blake --- common/include/ispowerof2.h | 9 +++++++++ common/include/test-ispowerof2.c | 15 +++++++++++++++ 2 files changed, 24 insertions(+)
diff --git a/common/include/ispowerof2.h b/common/include/ispowerof2.h index f067caf07..a4cb52de3 100644 --- a/common/include/ispowerof2.h +++ b/common/include/ispowerof2.h @@ -59,4 +59,13 @@ log_2_bits (unsigned long v) return SIZEOF_LONG*8 - __builtin_clzl (v) - 1; }
+/* Round up to next power of 2. + * https://jameshfisher.com/2018/03/30/round-up-power-2/ + */ +static inline uint64_t +next_power_of_2 (uint64_t x) +{ + return x <= 1 ? 1 : UINT64_C(1) << (64 - __builtin_clzll (x-1)); +}
Still mishandles anything >= INT64_MAX+1ULL. __builtin_clzll(0xffffffffffffffffULL - 1) gives 0, but UINT64_C(1) << (64-0) is undefined behavior. We've already declared elsewhere that the maximum size that nbdkit will handle is 2^63-1 (ie. INT64_MAX), not 2^64-1 (UINT64_MAX); this is because off_t is a signed value, and it gets really hard to work with anything larger than what off_t can hold. But it's still probably worth documenting what we want to do for out-of-range values, rather than blindly assuming that plugins will only use this function on values that are already appropriate as sizes. Maybe adjust the signature to: static inline uint64_t next_power_of_2 (int64_t x) where all negative input values map to (uint64_t)(-1) as an out-of-range indicator?
+ #endif /* NBDKIT_ISPOWEROF2_H */ diff --git a/common/include/test-ispowerof2.c b/common/include/test-ispowerof2.c index 9620192f0..1221ac09c 100644 --- a/common/include/test-ispowerof2.c +++ b/common/include/test-ispowerof2.c @@ -68,5 +68,20 @@ main (void) assert (log_2_bits (0x8000000000000000) == 63); #endif
+ /* Test next power of 2. */ + assert (next_power_of_2 (0) == 1);
Do we want this to be 1 (your choice of 'x <= 1 ? 1 : ...') or 0 (my suggestion of 'x <= 1 ? x : ...')?
+ assert (next_power_of_2 (1) == 1); + assert (next_power_of_2 (3) == 4); + assert (next_power_of_2 (8) == 8); + assert (next_power_of_2 (9) == 16); + assert (next_power_of_2 (0xffff) == 0x10000); + assert (next_power_of_2 (0x10000) == 0x10000); + assert (next_power_of_2 (UINT64_C ( 0xffffffff)) == 0x100000000); + assert (next_power_of_2 (UINT64_C (0x100000000)) == 0x100000000); + assert (next_power_of_2 (UINT64_C (0x200000001)) == 0x400000000); + assert (next_power_of_2 (UINT64_C (0x6ffffffff)) == 0x800000000); + assert (next_power_of_2 (UINT64_C (0x700000001)) == 0x800000000); + assert (next_power_of_2 (UINT64_C (0x800000000)) == 0x800000000);
While this tests that you handle more than 32 bits, it still doesn't test what happens when the most-significant bit is set (there's the special case of 0x8000000000000000ULL returning itself; all other values goes back to my question of whether we should have some sentinel for out-of-range). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org