[PATCH] D53927: [AArch64] Enable libm vectorized functions via SLEEF

[Renato Golin via Phabricator via llvm-commits]

rengolin added a comment.

In D53927#1327204 <https://reviews.llvm.org/D53927#1327204>, @steleman wrote:

> Then they are in trouble with a hypothetical distro SLEEF.
>
> That's because no commercial distro - if they ever decide to include SLEEF - will compile SLEEF for the maximum CPU feature-set possible. They do the exact opposite - they compile it for the lowest possible common denominator.
>
> For example, on AArch64, you won't get distro libraries compiled specifically for -mcpu=thunderx2t99. Or on x86_64 you'll never get -mavx512ifma, for example.


A bit off topic, but there are two solutions to that problem:

1. Dynamic Arch

The likes of IFUNC and virtual dispatch, which compiles all variants, but chooses the right one at run time. OpenBLAS uses this, for example.

This is easy on the compiler, which knows all variables at build time and no user are harmed in the process. But it's hard to maintain and has additional runtime costs.

2. Modules / Overlays

LMod, EasyBuild, Spack can choose the appropriate libraries at build / run time as needed.

That's not so easy on the compiler, especially if the modules are shared libraries, linked at runtime. It gets worse if users build half local and half use the modules.

Both are preferable to having every cluster user re-compile the whole stack every time, or having cluster admins curate a random number of random builds at random places (which is usually the end result).

That is also assuming the user knows how to best compile the libraries, better than the developers or packagers, which is usually not true.

For example, just adding `march` / `mtune` to OpenBLAS doesn't do much good and only improves a fraction of forcing the right arch via `TARGET=ARCH`, which then will select the right flags anyway.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53927/new/

https://reviews.llvm.org/D53927