This is the mail archive of the mailing list for the GCC 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: GNU C library's libmvec and the GNU Compiler *Collection*.

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;
   5280       case ix86_veclibabi_type_acml:
   5281         ix86_veclib_handler = ix86_veclibabi_acml;
   5282         break;
   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: - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home:; weather:
Progress of GNU Fortran:

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