[llvm-dev] [RFC][VECLIB] how should we legalize VECLIB calls? (original) (raw)

Naoki Shibata via llvm-dev llvm-dev at lists.llvm.org
Sat Oct 13 01:20:58 PDT 2018

On 10/11/2018 8:11 PM, Renato Golin via llvm-dev wrote:

On Wed, 10 Oct 2018 at 21:18, Francesco Petrogalli <Francesco.Petrogalli at arm.com> wrote:

_I am not sure I understand this. Are you saying that the signature of svmlsin8 might not conform to the signature that the intel vector function ABI mandates for a 8 lanes version of sin operating on double? Or is it just a difference in names that raises concerns for SVML? If the latter, I believe that the problem is easily solvable with OpenMP5.0. If the former, it gets indeed more complicated. Neither. :) My point is that GNU, Arm, Intel, IBM (usually) publish documents outlining their ABIs and they tend to stick to them. Not all library vendors do, or need to. Tracking changes in the stable ABIs is a long process and everyone pays the cost, but tracking (perhaps more frequent and unpredictable) changes in some other libraries could not only mean trunk (or maybe even a release) will have broken support for some library (that we officially support), but also it could increase the cost of maintaining (and identifying) all past variants and applying the correct ones. I don't personally know how stable SVML, SLEEF and others are, and how much of a standardisation process they have, so the comment may be moot. But it's a point to consider for all libraries once we introduce a more "generic" way of replacing functions that still needs compiler support (ie. not OMP5).

What kind of a standardization process are you talking about? As a developer of SLEEF, I am rather trying to know what is actually needed by the developers of compilers. I am also trying to come up with a new feature with which I can write a paper.

It would be easy if LLVM community will list up requirements. Then, SLEEF project will try to make the library comply to those requirements. This would be actually a matter of who will undertake the cumbersome task for setting the direction of implementation.

In my opinion, the first thing we need to consider is who is actually in need of vector math library.

  1. As for users of a compiler who don't care so much about how optimization is done : If the main thing these people care about is that the existing software works correctly, and they don't tolerate performance degradation by overdoing optimization, then I think vector math library is not needed for these people, for at least some time.

Considering about people in this category, I think the compiler should not vectorize the code by default. It would be also better to document that there is some risk of performance degradation if too much vectorization is introduced. It is sometimes not very easy to understand the difference between out-of-order execution and SIMD.

  1. As for the users of a compiler who wants ultimate optimization and are trying to make the compiler generate assembly code as they want : what they need is some way to fine tune how the code will be vectorized.

What these people need is function attributes with which how code is vectorized can be specified in a detailed way.

  1. As for the developers of a compiler who are caring mainly about the benchmark score : compiler has functionality to decide how the code is vectorized by itself. I think LTO should be used when benchmark programs are compiled.

The second thing we need to consider is compiler's compliance to the standard. The troublesome thing is that libraries may not be fully compliant to the C standard. We need to think of accuracy, input domain, whether it produces consistent results, etc. The number of items can increase, and developers of different libraries may be seeing different demands.

It is better if some condition is indicated for a vector math library to be treated with some default-ish setting. Is it good enough if the function has 1 ULP accuracy and full FP input domain? With this default-ish setting, interchangeability between vector math libraries should be also guaranteed, to some degree.

For non-default math functions which are faster but less accurate or with narrower input range, I think the developer of the code that will call such functions should be fully aware which particular library/functions they are trying to use. IMO, these functions should not be introduced automatically. fast-math options are too simple and too rough, and introducing many compiler options for making the compiler decide which functions can be used is too troublesome. I think the easiest way is to let the users choose which functions to be replaced during vectorization by macros and headers, and probably such functionality can be implemented with OMP5.

Another thing I want to know is how much compliance to the Vector Function ABI is needed. I know Arm is keen in supporting this ABI, but how about Intel? Is there possibility that SVML will comply to the Vector Function ABI in the near future?

Naoki Shibata

More information about the llvm-dev mailing list