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

[Renato Golin via Phabricator via llvm-commits]

rengolin added inline comments.


================
Comment at: llvm/trunk/lib/Analysis/TargetLibraryInfo.cpp:29
+                          "Intel SVML library"),
+               clEnumValN(TargetLibraryInfoImpl::SLEEFGNUABI, "sleefgnuabi",
+                          "SIMD Library for Evaluating Elementary Functions")));
----------------
fpetrogalli wrote:
> rengolin wrote:
> > fpetrogalli wrote:
> > > rengolin wrote:
> > > > A quick google search told me GCC uses `-fveclib=SLEEF`. We don't want to be different or that would create big problems in build systems. It seems, at least right now, there's only one ABI, so there's no point in premature classification.
> > > Hi @rengolin  - where did you find this option? I am struggling to find it in the gcc code base and in the gcc developer mailing lists. GCC uses -mveclibabi, but it is only for x86.
> > Hum, now I'm struggling to find it, too. I may have hit a sweet spot between `sleef` from clang and `mveclibabi` from gcc and assumed it worked.
> > 
> > This page [1] tells me only `svml` and `acml` are supported, so I stand corrected. However, if/when gcc supports it, `mveclibabi=sleefgnuabi` will be very weird. So I still prefer `sleef` instead of `sleefgnuabi`.
> > 
> > Also, why do we use `fveclib` and not `mveclibabi`? This isn't really helpful for build systems...
> > 
> > [1] https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
> 
> I proposed to use -whateveroption=SLEEFGNUABI instead of -whateveroption=SLEEF because SLEEF is produced in two version: libsleef.so and libsleefgnuabi.so. The two libraries have different signatures and naming conventions. The GNUABI version is compatible with the names of the Vector Function ABI of x86 and AArch64, and with the signature of the functions in glibc, which makes it a superior choice as it adheres to standards. That is why I think this patch is making the right choice in choosing the GNUABI names.
> 
> Now, although we might have personal preferences on how to name things (I agree with you that mveclibabi|fveclib=sleefgnuabi is not pretty), I think the ultimate criteria for our choice is correctness and clarity. Having -fveclib=SLEEF when the compiler will be really using libsleefgnuabi.so would just be confusing, especially if some day we decide that we want to support also libsleef.so (for example, some workloads might prefer the `sincos` signature in there over the one provided in libsleefgnuabi).
> 
Is there any realistic expectation that we should support two ABIs for the same library with one being incompatible with the other ABIs (x86, Arm, Gnu)?

If these are just aliases, we don't even need to have two SO objects, and just add the aliases and wrappers to the main SO. We do that in Compiler-RT because it would be a nightmare otherwise.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D53927