This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Fri, 2014-09-12 at 11:10 -0400, Carlos O'Donell wrote:
> On 09/12/2014 11:01 AM, H.J. Lu wrote:
> > On Thu, Sep 11, 2014 at 5:10 PM, Carlos O'Donell <> 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.

>From a long-term maintenance perspective, it seems easier to support
higher-level SIMD / vectorization abstractions in programming languages
than glibc APIs for each and every HW vector instruction variant.  We'd
have an ABI to maintain too if we chose the runtime library route, but
then at least it's not another glibc API.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]