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

Stefan Teleman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 20 07:50:44 PST 2018


steleman added a comment.

In https://reviews.llvm.org/D53927#1304262, @fpetrogalli wrote:

> @joel_k_jones , @steleman




> I will approve the patch and you will be able to submit it, but before doing that I would like to ask another tiny change.
> 
> I would like to change the value of the option from -fveclib=SLEEFGNUABI to -fveclib=SLEEFGNUABI10. The rest of the patch can stay the same.
> 
> By specifying “10” at the end of the option value, it will be clear to the user that they are using high precision functions. In the future, we might add the 3.5 ULP ones with the option SLEEFGNUABI35.

This is completely unnecessary.

Whether or not SLEEF uses ULP 1.0 or ULP 3.5 will be determined by -ffast-math passed on compile-line. There is no need to invent two or more different argument values for SLEEF.

For now, SLEEF will use ULP 1.0 exclusively.

When TargetLibraryInfo is expanded to capture the information about -mcpu=, -march=, -mtune= and -ffast-math, the choice between ULP 1.0 and ULP 3.5 will happen silently at compile-time.

There is no need for having two or more different argument values for -fveclib=sleefgnuabi.

This opens the door for having potentially N number of possible values for -fveclib=sleefgnuabi. That's confusing to the end-user and it doesn't follow the existing model already implemented by Intel with SVML.


https://reviews.llvm.org/D53927





More information about the llvm-commits mailing list