[libc-commits] [libc] [libc][mathvec] Add loop over scalar for unary FP32 (PR #199273)

Joseph Huber via libc-commits libc-commits at lists.llvm.org
Fri Jun 19 06:10:47 PDT 2026


================
@@ -0,0 +1,34 @@
+//===-- Implementation header for SIMD acosf ------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_LIBC_SRC___SUPPORT_MATHVEC_ACOSF_H
+#define LLVM_LIBC_SRC___SUPPORT_MATHVEC_ACOSF_H
+
+#include "src/__support/CPP/simd.h"
+#define LIBC_MATH (LIBC_MATH_NO_ERRNO | LIBC_MATH_NO_EXCEPT)
+#include "src/__support/math/acosf.h"
+
+namespace LIBC_NAMESPACE_DECL {
+
+namespace mathvec {
+
+template <size_t N>
+LIBC_INLINE cpp::simd<float, N> acosf(cpp::simd<float, N> x) {
+  cpp::simd<float, N> result;
----------------
jhuber6 wrote:

I would really, really prefer we do not add yet another C++ SIMD wrapper class.. The entire point of using LLVM vectors is that you can treat them as fundamental types. If you wrap this in a class, you lose the ability to use the overloads and builtins that apply to them, like __builtin_elementwise_xyz. Personally, I think C++26 SIMD was half-baked and I don't think we should bother trying to faithfully recreate it.

You could create a helper function with what we already have
```c++
  template <typename T, size_t N, typename F>
  LIBC_INLINE static cpp::simd<T, N> map(cpp::simd<T, N> v, F f) {
    cpp::simd<T, N> r;
    LIBC_LOOP_UNROLL
    for (size_t i = 0; i < N; ++i)
      r[i] = f(v[i]);
    return r;
  }

  LIBC_INLINE cpp::simd<float> sinf(cpp::simd<float> x) {
    return map(x, [](float v) { return LIBC_NAMESPACE::sinf(v); });
  }
```

If you are hellbent on heading this direction it would be much more fruitful to just copy-paste Google's Highway code, at least that would give you compatibility between GCC and Clang. But I'm not exactly a fan of that either.

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


More information about the libc-commits mailing list