[libc-commits] [libc] [libc][math][c23] Optimize fabsf16 on x86 with Clang (PR #104869)

Matt Arsenault via libc-commits libc-commits at lists.llvm.org
Tue Aug 20 00:14:43 PDT 2024


================
@@ -8,19 +8,30 @@
 
 #include "src/math/fabsf16.h"
 #include "src/__support/FPUtil/BasicOperations.h"
+#include "src/__support/FPUtil/FPBits.h"
 #include "src/__support/common.h"
 #include "src/__support/macros/config.h"
 #include "src/__support/macros/properties/architectures.h"
 #include "src/__support/macros/properties/compiler.h"
+#include "src/__support/macros/properties/cpu_features.h"
 
 namespace LIBC_NAMESPACE_DECL {
 
 LLVM_LIBC_FUNCTION(float16, fabsf16, (float16 x)) {
-  // For x86, GCC generates better code from the generic implementation.
-  // https://godbolt.org/z/K9orM4hTa
 #if defined(__LIBC_MISC_MATH_BASIC_OPS_OPT) &&                                 \
-    !(defined(LIBC_TARGET_ARCH_IS_X86) && defined(LIBC_COMPILER_IS_GCC))
+    defined(LIBC_TARGET_CPU_HAS_FAST_FLOAT16_OPS)
   return __builtin_fabsf16(x);
+#elif defined(LIBC_TARGET_ARCH_IS_X86) && defined(LIBC_COMPILER_IS_CLANG)
+  // Prevent Clang from generating calls to slow soft-float conversion
+  // functions on x86. See https://godbolt.org/z/hvo6jbnGz.
----------------
arsenm wrote:

This is just a codegen bug. it's wrong to introduce a canonicalizing extend when legalizing fabs. Don't workaround it here? 

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


More information about the libc-commits mailing list