[llvm] [TLI] Add glibc 2.35 libmvec vector functions to the x86 table (PR #223817)

via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 24 21:54:16 PDT 2026


anun333 wrote:

@tonuonu thanks for checking it on two machines, and for the controls. I've pushed a commit that takes your first option. It keeps the 46 new `_ZGVb` rows (24 symbols), which are valid on every x86-64 target, and drops the 46 new `_ZGVd` rows until #162239 is fixed. It doesn't touch the `_ZGVd` rows that were already in the table.

Both autogenerated tests are regenerated. In `replace-with-veclib-libmvec.ll` the `<4 x double>` and `<8 x float>` cases for the new functions are kept, now checking that they stay as intrinsics, so when the rows come back the diff there will show it. On an assertions build, the three changed tests and the other x86 tests that use `-vector-library=LIBMVEC` pass, and your `exp2((double)float)` case at `-march=x86-64` now calls `_ZGVbN2v_exp2`, with 0/64 wrong. I'll update the description to match.

One data point for when the `_ZGVd` rows come back: I built PoCL (OpenCL on CPU) against LLVM with the full PR, on AVX2 with glibc 2.39. The OpenCL CTS `math_brute_force` kernels called both the `_ZGVb` and `_ZGVd` variants of `sinh`, `cosh`, `tanh`, `asin`, `acos`, `atan`, `exp2`, `log2`, `log10` and `exp10`, and all ten passed the OpenCL accuracy bounds in float and double.


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


More information about the llvm-commits mailing list