On Thu, Jan 7, 2016 at 7:41 PM, Toon Moene <t...@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: t...@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
