This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GNU C library's libmvec and the GNU Compiler *Collection*.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Toon Moene <toon at moene dot org>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 8 Jan 2016 12:10:26 +0100
- Subject: Re: GNU C library's libmvec and the GNU Compiler *Collection*.
- Authentication-results: sourceware.org; auth=none
- References: <568D611F dot 4020805 at moene dot org> <568EB149 dot 5090802 at moene dot org>
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