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

[Naoki Shibata via llvm-dev]

Hello Renato,

On 10/14/2018 12:05 AM, Renato Golin wrote:
> Hi Naoki,
> 
> I'll try to keep it short, as this is not the most important part of
> this thread. If that's too short, I'll be glad to chat in private.
> 
> On Sat, 13 Oct 2018 at 09:20, Naoki Shibata <n-sibata at is.naist.jp> wrote:
>> 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.
> 
> I meant ABI standards. An official document, written by the authors of
> the library (company, community, developer), specifying things like
> function names and what they do, argument types and how they expand,
> how errors are handled, special registers used (if any), macros that
> control behaviour, macros that are defined by the library, etc.
> 
> This is the important part for compiler writers, not necessarily for
> users. End users of the compiler do not care at all what the ABIs are,
> they want their code compiled, correct results and fast execution.
> 
> Users of your library won't care much either, as if you change the
> names or mandatory arguments or even internal behaviour, they'll adapt
> to the new model. Most users only use one version of each library
> anyway.
> 
> But when embedding the behaviour of your library (alongside all other
> similar libraries) in the compiler, and you change the behaviour in
> the new version, the compiler now has to be compatible with two
> versions.
> 
> Furthermore, if you don't follow the same behaviour (as you would have
> if there's an official ABI document), then we'd only notice you
> changed when our users start complaining *we* are breaking their code.
> 
> A good example of an official ABI document is what ARM publishes for
> their architecture:
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html
> 
> But there are a lot of documents in there, and that's not what I'm
> asking. Something like the NEON intrinsics list would be a good start:
> 
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073b/IHI0073B_arm_neon_intrinsics_ref.pdf
> 
> But it would be better with a short explanation of what the function
> does, what the arguments are and what is the results returned.

Your stance seems to be that it is compiler's responsibility to adapt to 
the changes of math libraries, but is it fair to say that? I would say 
there should be a kind of standard regarding to how a vector math 
library is implemented. Then, the compiler can simply assume that the 
library is implemented conforming to that standard. It would be even 
better if there is a conformance testing tool.

In order to make the compiler compliant to the C standard, the standard 
library also needs to be compliant to the C standard. Documenting what 
is assumed by the compiler should be not too hard, since there is 
already documents for C standard library and documents for the Vector ABI.


>> 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.
> 
> This is largely irrelevant to the topic of this thread. How you
> compile your library is up to you, this thread is about the
> expectation of what are the entry points of the library (functions,
> arguments) and returned values and types, so that we can replace
> scalar functions (already checked by the front-end) with vector
> alternatives (not checked by anyone).

I am saying about this because you said:

> One thing is to produce slow code because you didn't do enough,
> another is because you did too much. People often understand the
> former, not usually the latter. 

The problem is that there are things that are not visible from the 
current compiler, which are accuracy, input domain and performance. If 
the compiled program does not give enough accuracy as it is designed, it 
would also upset the users.

If you want to make the compiler choose the fastest functions in the 
math libraries, we need at least a way to express how much performance 
each function in the libraries provides. This is not a trivial thing. 
The compiler also needs additional code for processing these figures. 
The merit of LTO is that we can avoid the problem of expressing 
performance. Since the compiler can see through everything in the 
library, the existing optimization passes can be used without changes.

For accuracy, the only thing we can do is to make assumptions. The 
easiest assumption is that the functions in a vector math library 
conforms to the ANSI C standard and Vector ABI.


>> 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?
> 
> That's a good questions and is mostly up to all of us to make sure
> that works in the future. If we all have clear expectations (and an
> official document goes a long way in providing that), then we'll all
> have a much easier job.
> 
> Hope this helps.


Naoki Shibta