[compiler-rt] [compiler-rt] Make sure __clzdi2 doesn't call itself recursively on sparc64 (PR #136737)

[via llvm-commits]

================
@@ -14,12 +14,12 @@
 
 // Returns: the number of leading 0-bits
 
-#if !defined(__clang__) &&                                                     \
-    ((defined(__sparc__) && defined(__arch64__)) || defined(__mips64) ||       \
+#if ((defined(__sparc__) && defined(__arch64__)) || defined(__mips64) ||       \
      (defined(__riscv) && __SIZEOF_POINTER__ >= 8))
 // On 64-bit architectures with neither a native clz instruction nor a native
-// ctz instruction, gcc resolves __builtin_clz to __clzdi2 rather than
-// __clzsi2, leading to infinite recursion.
+// ctz instruction, `__builtin_clz` resolves to `__clzdi2` rather than
+// __clzsi2 as libgcc does not ship with `__clzsi2`, leading to infinite
+// recursion.
 #define __builtin_clz(a) __clzsi2(a)
----------------
koachan wrote:

The `__clzdi2` implementation here calls `clzsi` at [line 33](https://github.com/llvm/llvm-project/pull/136737/files#diff-b56e817fdee161ea9d5b8995657b599a06f82cf647c324969c6fa01a94e74873R33)  which [resolves to `__builtin_clz`](https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/int_types.h#L28).
On the other hand, GCC (and now, clang on sparc64) resolves `__builtin_clz` to `__clzdi2`. This causes infinite recursion.

So here we `#define`d __builtin_clz away to __clzsi2 to break the cycle.

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