[PATCH v4 0/1] Add vector math function acos/acosf to libmvec

[Adhemerval Zanella]

On 19/12/2021 17:34, H.J. Lu wrote:
> On Thu, Dec 16, 2021 at 06:13:32PM -0300, GNU C Library wrote:
>>
>>
>> On 16/12/2021 16:18, Joseph Myers wrote:
>>> I'd like to know more about where this assembly code came from.  Is it 
>>> manually written?  Generated by a compiler and then manually edited, as 
>>> suggested in previous discussions?  If it was generated by a compiler but 
>>> then sufficiently edited that the assembly version is now the preferred 
>>> form for subsequent modifications, it would still be helpful to see the 
>>> original input to that compiler (e.g. as a comment in the .S files), in 
>>> order to assess the relative merits of C and assembly sources for this 
>>> code and the possibilities of adapting to other architectures - and also 
>>> to see the original compiler output so we can judge the extent of the 
>>> editing and work out what is in fact the preferred form for modifications.
>>>
>>
>>
>> Besides it I am curious why it can't be coded in C with proper builtins
>> plus some portability wrapper, as libraries like SLEEF does.  With some 
>> care we can make generic code that can ported to other vector ABIs, and 
>> add optimizations only its is really requires (as FMA for the newer math
>> functions).
> 
> libmvec functions are from Intel SVML library, which are x86-64 sepecific.
> They need to be compiled by a special version of Intel compiler for
> correctness, performance and accuracy.  We do post-processing on Intel
> compiler generated codes for glibc contribution.

>From the weekly call, If I understood correctly these assembly routines
are build from another high level language to C implementation and then
the Intel compiler will generate the assembly which will post-processed in
the current form.

I am not sure if this is the best course of action, specially because
we don't have access neither to the high-level code, nor to theused compiler
to generate such assembly routines.  I give that the resulting code might
better than C code the tool dumps, but all these process are really hard to
justify in a open-source tool like glibc.

What I meant why not use something like SLEEF is that using the C as
the base source for the high code generation might better to describe
the whole process and generates more understandably and maintainable
code that could be reused more easily to different architecture and vector
ABIs.

I give you that it might no generate the most optimized and fine-tuned
code, but it also leverages compiler support and move to the current
practice to remove arch-specific tuned implementations in favor of
C generic ones.

For instance, SLEEF code for vector cosf implementation [1], uses slim
wrapper (vlt_vo_vf_vf for instance) that is reimplemented by each vector
ABI [1].  It can be easily adapted to different vector ABIs without
much work.

[1] https://github.com/shibatch/sleef/blob/master/src/libm/sleefsimdsp.c
[2] https://github.com/shibatch/sleef/blob/master/src/arch/helperavx512f.h