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

[Richard Guenther <rguenther at suse dot de>]

On Tue, 28 Nov 2006, Dorit Nuzman wrote:

> >
> > On Sun, 26 Nov 2006, Richard Guenther wrote:
> > > 2006-11-16  Richard Guenther  <rguenther@suse.de>
> > >    Zdenek Dvorak <dvorakz@suse.cz>
> > >
> > >    * target.h (struct gcc_target): Add builtin_vectorized_function
> > >    target hook.
> > >    * target-def.h (TARGET_VECTORIZE): Likewise.
> > >    * targhooks.h (default_builtin_vectorized_function): Declare.
> > >    * targhooks.c (default_builtin_vectorized_function): Define.
> > >    * tree-vectorizer.h (stmt_vec_info_type): Add call_vec_info_type.
> > >    (vectorizable_call): Declare.
> > >    * tree-vect-analyze.c (vect_analyze_operations): Call
> > >    vectorizable_call.
> > >    * tree-vect-transform.c (vectorizable_function): New static
> function.
> > >    (build_vectorized_function_call): Likewise.
> > >    (vectorizable_call): New function.
> > >    (vect_transform_stmt): Handle vectorizable calls.
> >
> > 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?
> 
> On the PPU/powerpc side, would be nice to use some Altivec math library
> (e.g. something like http://www.freevec.org/ ?)?

If libgcc-math works out it would be a natural place to stick these
parts.  This eases gcc configuration and usage.

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).

Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs