GNU C library's libmvec and the GNU Compiler *Collection*.

Toon Moene toon@moene.org
Thu Jan 7 18:41:00 GMT 2016


On 01/06/2016 07:46 PM, Toon Moene wrote:

> Would it be possible to add an option -mveclibabi=glibc to cater for
> this *for all languages*; or is this too low level (after all, the glibc
> libmvec has code for multiple architectures). If so, at what level
> should this be implemented ?

It doesn't look hard to implement this as a variant of 
-mveclibabi={svml|acml}.

The implementation of these options is in config/i386/i386.c:

    5272   /* Use external vectorized library in vectorizing intrinsics.  */
    5273   if (opts_set->x_ix86_veclibabi_type)
    5274     switch (opts->x_ix86_veclibabi_type)
    5275       {
    5276       case ix86_veclibabi_type_svml:
    5277         ix86_veclib_handler = ix86_veclibabi_svml;
    5278         break;
    5279
    5280       case ix86_veclibabi_type_acml:
    5281         ix86_veclib_handler = ix86_veclibabi_acml;
    5282         break;
    5283
    5284       default:
    5285         gcc_unreachable ();
    5286       }

so I could just write a third "handler":

case ix86_veclibabi_type_glibc:
   ix86_veclib_handler = ix86_veclibabi_glibc;

and clone, say, ix86_veclibabi_svml to write ix86_veclibabi_glibc to do 
the right thing for generating calls to the glibc libmvec routines.

I hope to have time for this during the summer. As this is stage 1 
material anyway, that looks like the right point in time anyway.

Of course, a more general, architecture independent approach might be 
preferable, but this at least would be a start.

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news



More information about the Gcc mailing list