| Index: third_party/WebKit/Source/wtf/BitwiseOperations.h
|
| diff --git a/third_party/WebKit/Source/wtf/BitwiseOperations.h b/third_party/WebKit/Source/wtf/BitwiseOperations.h
|
| index 2e6d2774fe1a002f2e97f16275c70394b6758efa..e07227a15d2e19a4f841544f2713766823d9d97c 100644
|
| --- a/third_party/WebKit/Source/wtf/BitwiseOperations.h
|
| +++ b/third_party/WebKit/Source/wtf/BitwiseOperations.h
|
| @@ -28,72 +28,23 @@
|
| * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
| */
|
|
|
| +// TODO(palmer): The only caller of this code in Blink is PartitionAlloc. When
|
| +// PA is moved to base, we can remove this file.
|
| +// https://bugs.chromium.org/p/chromium/issues/detail?id=632441
|
| +
|
| #ifndef WTF_BitwiseOperations_h
|
| #define WTF_BitwiseOperations_h
|
|
|
| -// DESCRIPTION
|
| -// countLeadingZeros() is a bitwise operation that counts the number of leading
|
| -// zeros in a binary value, starting with the most significant bit. C does not
|
| -// have an operator to do this, but fortunately the various compilers have
|
| -// built-ins that map to fast underlying processor instructions.
|
| -
|
| +#include "base/bits.h"
|
| #include "wtf/CPU.h"
|
| -#include "wtf/Compiler.h"
|
| -#include <cstddef>
|
| -#include <stdint.h>
|
| -
|
| -#if COMPILER(MSVC)
|
| -#include <intrin.h>
|
| -#endif
|
|
|
| namespace WTF {
|
|
|
| -#if COMPILER(MSVC)
|
| -
|
| -ALWAYS_INLINE uint32_t countLeadingZeros32(uint32_t x) {
|
| - unsigned long index;
|
| - return LIKELY(_BitScanReverse(&index, x)) ? (31 - index) : 32;
|
| -}
|
| +using base::bits::CountLeadingZeroBits32;
|
| +using base::bits::CountLeadingZeroBitsSizeT;
|
|
|
| #if CPU(64BIT)
|
| -
|
| -// MSVC only supplies _BitScanForward64 when building for a 64-bit target.
|
| -ALWAYS_INLINE uint64_t countLeadingZeros64(uint64_t x) {
|
| - unsigned long index;
|
| - return LIKELY(_BitScanReverse64(&index, x)) ? (63 - index) : 64;
|
| -}
|
| -
|
| -#endif
|
| -
|
| -#elif COMPILER(GCC)
|
| -
|
| -// This is very annoying. __builtin_clz has undefined behaviour for an input of
|
| -// 0, even though these's clearly a return value that makes sense, and even
|
| -// though nascent processor clz instructions have defined behaviour for 0.
|
| -// We could drop to raw __asm__ to do better, but we'll avoid doing that unless
|
| -// we see proof that we need to.
|
| -ALWAYS_INLINE uint32_t countLeadingZeros32(uint32_t x) {
|
| - return LIKELY(x) ? __builtin_clz(x) : 32;
|
| -}
|
| -
|
| -ALWAYS_INLINE uint64_t countLeadingZeros64(uint64_t x) {
|
| - return LIKELY(x) ? __builtin_clzll(x) : 64;
|
| -}
|
| -
|
| -#endif
|
| -
|
| -#if CPU(64BIT)
|
| -
|
| -ALWAYS_INLINE size_t countLeadingZerosSizet(size_t x) {
|
| - return countLeadingZeros64(x);
|
| -}
|
| -
|
| -#else
|
| -
|
| -ALWAYS_INLINE size_t countLeadingZerosSizet(size_t x) {
|
| - return countLeadingZeros32(x);
|
| -}
|
| -
|
| +using base::bits::CountLeadingZeroBits64;
|
| #endif
|
|
|
| } // namespace WTF
|
|
|