Re: [PATCH][PING] Add vectorization of builtin functions

[Dorit Nuzman <DORIT at il dot ibm dot com>]

Richard Guenther <rguenther@suse.de> wrote on 30/11/2006 16:22:14:

> > > This is OK for mainline, assuming that the vectorization folks have
no
> > > objections.  This infrastructure looks to be independent of the other
> > > pieces, so presumably can be committed before resurecting libgcc-math
> > > library (though my vote is that your exisiting maintainership is
still
> > > valid) or adding the x86 backend support.  Is there anyone
investigating
> > > vectorized math support for the other backends?
> > >
> >
> > We'd probably want to exploit this feature for the Cell backend.
> >
> > On the SPU side, a simd math lib would probably be made available in
the
> > near future; the question is - do the library functions have to be
provided
> > with GCC, like Richard Guenther's implementation for AMD, or could we
rely
> > on the library to be present as an external package?
> >
> If libgcc-math works out it would be a natural place to stick these
> parts.  This eases gcc configuration and usage.
>

but only for cases in which you can make the library code available with
gcc.
Andrew, do you know if that's going to be the case with the "SIMD Math
library for the Cell BEA"
(as you mention in -
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00019.html)?

> My fallback plan is to support target/OS dependent vector libraries
> similar to fortran -fexternal-blas, let's call it -fvecmath.  At
> configure time the system provider could choose a kind of vector
> library he wants to support (like Intel MKL or AMD MKL) with
> --enable-vecmath=intel-mkl which the target/OS config could then
> use for enabling the right set of transformations (sin -> __sse2_sinv
> in case of Intel MKL, other symbols in other cases).  We could even
> try to support multiple libraries, but then automatically linking
> both with -fvecmath could create symbol conflicts.  Or allow
> configuring for multiple libraries but only enable one with
> -fvecmath=intel-mkl and let the target sort out things.
>
> The problem is really while for -fexternal-blas the ABI to the
> library is well-defined it differs for the different vector
> libraries (there's even PR22226 requesting support for IBM MASSV
> or Intel VML libraries).
>
> But before I start working on the infrastructure part of such
> change I'd rather have a decision on libgcc-math (to not waste
> my time twice).
>

sounds like there's room for both approaches?

> > On the PPU/powerpc side, would be nice to use some Altivec math library
> > (e.g. something like http://www.freevec.org/ ?)?
>

on second look - freevec doesn't look so relevant - it's not a vector-API
math lib, but
rather a vectorized implementation of standard GLIBC memory/string
functions.

Anyone knows a non proprietary math library for Altivec that we could make
available with gcc, using the libgcc-math scheme?

dorit