[llvm] [Support] Fix xxh3_128bits for Win32 builds (PR #96931)

[via llvm-commits]

llvmbot wrote:


<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-llvm-support

Author: Fangrui Song (MaskRay)

<details>
<summary>Changes</summary>

`__emulu` is used without including `intrin.h`. Actually, it's better to
rely on compiler optimizations. In this LLVM copy, we try to eliminate
unneceeded workarounds for old compilers.


---
Full diff: https://github.com/llvm/llvm-project/pull/96931.diff


1 Files Affected:

- (modified) llvm/lib/Support/xxhash.cpp (-11) 


``````````diff
diff --git a/llvm/lib/Support/xxhash.cpp b/llvm/lib/Support/xxhash.cpp
index a0803297555ce..607789b391381 100644
--- a/llvm/lib/Support/xxhash.cpp
+++ b/llvm/lib/Support/xxhash.cpp
@@ -453,18 +453,7 @@ uint64_t llvm::xxh3_64bits(ArrayRef<uint8_t> data) {
 #define XXH_rotl64(x, r) (((x) << (r)) | ((x) >> (64 - (r))))
 #endif
 
-#if defined(_MSC_VER) && defined(_M_IX86)
-#define XXH_mult32to64(x, y) __emulu((unsigned)(x), (unsigned)(y))
-#else
-/*
- * Downcast + upcast is usually better than masking on older compilers like
- * GCC 4.2 (especially 32-bit ones), all without affecting newer compilers.
- *
- * The other method, (x & 0xFFFFFFFF) * (y & 0xFFFFFFFF), will AND both operands
- * and perform a full 64x64 multiply -- entirely redundant on 32-bit.
- */
 #define XXH_mult32to64(x, y) ((uint64_t)(uint32_t)(x) * (uint64_t)(uint32_t)(y))
-#endif
 
 /*!
  * @brief Calculates a 64->128-bit long multiply.

``````````

</details>


https://github.com/llvm/llvm-project/pull/96931