63358eaff6
log2(1) is 0 and log2(0) is -1. If we have the int64_t 0xffffffff then log2(0xffffffff >> 31) = log2(0x1) = 0, so the current reduction code would not shift. That's a bad idea, though, since 0xffffffff when interpreted as an int32_t would become a negative number. We need to always shift one more than the current code does to get a safe reduction. This also means we can get rid of another compare/branch since -1 is the smallest result log2() can return, so the shift can no longer go negative now. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ib1eb6364c35c26924804261c02171139cdbd1034 Reviewed-on: https://review.coreboot.org/c/coreboot/+/42845 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Joel Kitching <kitching@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> |
||
|---|---|---|
| .. | ||
| coreinfo | ||
| external | ||
| libpayload | ||
| linuxcheck | ||
| nvramcui | ||
| Kconfig | ||
| Makefile.inc | ||