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

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2014-09-12 at 13:37 -0400, Carlos O'Donell wrote:
> On 09/12/2014 12:00 PM, Torvald Riegel wrote:
> > 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 <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.
> > 
> > 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.
> 
> That is correct. However it also requires a much much much more complicated
> API design because it has to map optimally to an arbitrarily different
> future hardware design that we don't know of yet. We might extrapolate
> that AVX-512 -> 1024 -> 2048 -> 4096 etc, and design in that direction
> for all machines. Not to mention unified error reporting. It's a harder
> problem that exposing, for now, the vendor APIs as a starting point,
> as a place where the community can learn about the issues behind these
> APIs and design something new.

The language-level interfaces I was speaking about (they're not exactly
APIs) are different.  They have to expose some of the complexity you
mention (see the Cilk+ elemental functions), but hide a lot in the
compiler.  Standards-wise, the current direction does not seem to go
towards trying to have portable APIs for vector instructions, but rather
let programmers specify that SIMD parallelism is allowed and then give a
few hints about how a programmer-supplied function might be used (e.g.,
that one argument is always linear, etc.).  That's why I said that we'd
have complexity in the ABIs (and in the compiler), but are not exposing
a lot of that to programmers via APIs.