This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] How to add vector math functions to Glibc
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 26 Sep 2014 10:15:35 -0400
- Subject: Re: [RFC] How to add vector math functions to Glibc
- Authentication-results: sourceware.org; auth=none
- References: <CAMXFM3tjquzniXP1weqxSVFJyhXqsf2PHuyrrrmqp7K0ZzORqA at mail dot gmail dot com> <CAMXFM3sGMNX1DEPAMt7qUR4UREF_xUAQjCG1OjBiZH2aoOFiPA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409181551370 dot 31607 at digraph dot polyomino dot org dot uk> <CAMXFM3tO7MTYCq8-YFZacdbLvR4iAab_n04AuB+rp2Phs4BvQg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409242011260 dot 7597 at digraph dot polyomino dot org dot uk> <CAMXFM3tqiqUNuSU2KXvAFM-QescX3+6xUO9=z5X0Ac6C9qJ7zg at mail dot gmail dot com> <CAMe9rOq7bZHb8R=opUzSmAMGWjLpX21mR=Sx96cuBph=TTtDXA at mail dot gmail dot com> <54246CB5 dot 7020908 at redhat dot com> <CAMe9rOoLmJ2jHWmERoB0M83WNKovJOgh0--Kquw9O86A1tPU0g at mail dot gmail dot com> <5424733D dot 6010305 at redhat dot com> <CAMe9rOpacze055qyBFzz3M-b-GNtXCqZzMmkScBL9a94zVj28g at mail dot gmail dot com> <54247FAB dot 6050002 at redhat dot com> <CAMXFM3v8narOLMHC5U=fvyTFWV6s4ZACN-UrAC4fAcUs9SOFfA at mail dot gmail dot com>
On 09/26/2014 09:45 AM, Andrew Senkevich wrote:
> So lets discuss Glibc build changes.
> Build of libmvec (and hence libm.so installation) need to be
> architecture dependent and optional, and some changes already was
> discussed in https://sourceware.org/ml/libc-alpha/2014-09/msg00578.html.
> Is it OK additionally to have configure option --enable-mathvec with
> default=no and with default=yes for x86_86 build?
Under what circumstances would a non-x86_64 target build with
--enable-mathvec?
When they have their own API/ABI standard to implement and provide
in libmvec.so?
What's wrong with simply producing a libmvec.so that has no public
symbols?
It simplifies everything to just always ship libmvec.so, even if
it's empty.
Cheers,
Carlos.