[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