This is the mail archive of the gcc@gcc.gnu.org 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 Thu, Jan 7, 2016 at 7:41 PM, Toon Moene <toon@moene.org> wrote:
> 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.

Yes.

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

Might qualify for a backport though if sufficiently isolated.

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

Yeah, not sure if the glibc support will be platform agnostic, but the mangling
code should be in some general place.

Richard.

> 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


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