[llvm-dev] [RFC][VECLIB] how should we legalize VECLIB calls?

[Naoki Shibata via llvm-dev]

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 __svml_sin_8 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.

2. 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.

3. 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