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

[Renato Golin via Phabricator via llvm-commits]

rengolin added a comment.

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

> I am taking it on faith that SLEEF won't keep changing their mangling and ABI.
>  AFAICS, SLEEF isn't included in any Linux distro. I can't find any reference to it in RH/CentOS/Fedora, or at rpmfind. Or Ubuntu or SuSE.


As @shibatch said, they use Intel's and Arm's ABIs, so that should be fine. But also, that this is not just a distro issue, but bundling into other libraries.

> Which means that those environments who will want to use SLEEF will have to build their own.
>  The upside is that SLEEF is likely of interest only to the rarefied world of HPC/Super-computing. Those environments can definitely build their own SLEEF and maintain their own binary copy.

The signal I'm getting from all labs (in US, Europe and Asia) is that they really *don't* want to maintain their own binaries. They just cope with it because we don't do a good job at the tools/packaging level.

I'm not willing to add more chaos into the mix.

> Those environments can always use two different versions of SLEEF - one with SVE, the other one without, just by using different shared object names and different binding SONAMEs: one for SVE, the other one for not SVE.
>  clang doesn't auto-magically pass -lsleefgnuabi on link-line, so that's left up to the consumer.

SVE was just an example of completely missing options, but new functions and potentially renames can raise much harder issues to fix. We had such issues with glibc, libgcc, compiler-rt in the past and it takes awfully long to go away.

The link flag issue is minor, as people passing `-fveclib=sleef` to `CFLAGS` will also pass `-lsleef` to `LDFLAGS`, but that doesn't solve the versioning problem.

> 4. I am very happy about the thought of OpenMP being able - at some point in the future - to vectorize things. Programs that already use OpenMP will happily take advantage of this future feature. But, based on my understanding of the current OpenMP reality, this new OpenMP feature won't be available for a while. It's certainly not available now. So, how do we accomplish libm vectorization in the meanwhile?

The alternative is to call it experimental and take slow steps. This is mostly a political change, not technical, so it won't involve a lot of red tape. As I said before, the code looks fine to me.

What this normally means is:

- Commit messages and code comments have "experimental" in them
- A small paragraph of comments on the code explaining the problems with the current approach
- Developer availability to move code around or re-write in the near future

The bad side is that:

- Experimental features have less priority than other changes
- Other developers are far less likely to keep that part of the code in good shape
- If this code breaks some other, "official" code, it could be reverted or changed
- If no one takes the maintenance role, the code will bit rot and be eventually removed

A code moves from experimental to official when:

- There are enough users / developers maintaining it for months / year
- There are enough validation efforts (buildbots, new tests, distro use)
- The code, and its tests, don't break other unrelated changes often enough
- Developers usually respond promptly to such breakages

As I said, I still want to hear from Hal/Tim, but I'd be happy to call this experimental, as long as we're agreeing that there is a commitment to look after this code (and all ramifications, such as for OMP).

The commitment doesn't need to be from you directly, but from enough developers to make this worthwhile.

I just want to make clear I do want SLEEF support in LLVM, but we need to make it right from the start.

cheers,
--renato


Repository:
  rL LLVM

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

https://reviews.llvm.org/D53927