Re: [PATCH 1/N] x86_64 vectorization support: vectorized math functions addition to Glibc

["Carlos O'Donell" <carlos at redhat dot com>]

On 09/12/2014 03:05 PM, H.J. Lu wrote:
> On Fri, Sep 12, 2014 at 8:10 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 09/12/2014 11:01 AM, H.J. Lu wrote:
>>> On Thu, Sep 11, 2014 at 5:10 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>> On 09/11/2014 04:57 PM, H.J. Lu wrote:
>>>>>> That doesn't answer my question.  Maybe glibc 2.21 provides such versions
>>>>>> for all x86 ISAs there are at present, up to AVX512 - and then a new
>>>>>> extension AVX1024 appears.  When GCC 7 is used with glibc 2.21 headers and
>>>>>> -mavx1024, it must not try to generate calls to the AVX1024 functions,
>>>>>> because glibc 2.21 doesn't have such functions.  But maybe glibc 2.26 adds
>>>>>> the AVX1024 functions.  So something needs to be different in the headers
>>>>>> of 2.26 to inform GCC 7 that AVX1024 versions of the functions are
>>>>>> available.  And I think that means the directive that communicates
>>>>>> function availability to the compiler needs to identify the set of ISAs
>>>>>> for which versions of the function in question are available.
>>>>>>
>>>>>
>>>>> Wouldn't it be better to put libmvec in GCC instead?
>>>>
>>>> That's certainly a discussion we can have.
>>>>
>>>> What do you see as the pros and cons?
>>>>
>>>
>>> It depends on who are the main target users of this library.
>>> If it is mainly for programmers to use them directly in their
>>> applications, mostly independent of compilers, it should be
>>> in glibc.  But if it is mainly used by GCC, it should be in
>>> GCC, just like other run-time libraries.
>>
>> The former. I want users to be able to call these functions
>> directly regardless of the compiler. The same goes for the
>> ppc-related API that has been in use for a long time by
>> developers there.
>>
>> The compiler can certainly make use of these functions, and
>> any more standard cross-machine GNU API we design, but it
>> should always be possible to call them directly.
>>
>> Does this mean libmvec should be in glibc?
>>
> 
> If the target users are programmers,  we should make it easier
> to use for programmers.  We can provide a generic API with a
> generic implementation.  Each target can provide an optimized
> version which is transparent to users.  We can use IFUNC to
> select the best version at run-time.

I think such an implementation is orthogonal to exposing the
already documented vector functions supported by Intel?

Similarly for IBM.

First a foremost we should support users who are expecting
to be able to call the functions Intel and IBM have already
documented.

Second to that we can create a new API?

Note that the generic API might by very difficult to design,
which is why I don't suggest we tackle it first.

Cheers,
Carlos.