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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: Christoph Lauter <christoph dot lauter at lip6 dot fr>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 2 Oct 2014 14:21:34 +0000
- 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> <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> <54257507 dot 9070508 at redhat dot com> <CAMXFM3vOLspQtHxgJfD_Emht480w2RMbiwnEH6A_LhoS-JZFag at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409301620020 dot 15186 at digraph dot polyomino dot org dot uk> <542AF92E dot 8090708 at lip6 dot fr> <Pine dot LNX dot 4 dot 64 dot 1409302003410 dot 12188 at digraph dot polyomino dot org dot uk> <CAMXFM3tuM_p6Acp4hzoQ2xzR=4BZqtw8NbezqY6h8V4Xx=5hUA at mail dot gmail dot com>
On Thu, 2 Oct 2014, Andrew Senkevich wrote:
> >> > > + .align 64
> >> > > + .globl __gnu_svml_dcos_data
> >> > > +__gnu_svml_dcos_data:
> >> > > + .long 4294967295
> >> >
> >> > What are the semantics of the values in this table (please add a comment)?
>
> This tables contain data of several types - polynomial coefficients,
> some constants, lookup-tables.
That then indicates that each part of the table should have a comment
explaining the exact semantics of the values in that part of the table,
and naming the macro used for the offset of that part of the table from
the start of the table - and where the code refers to parts of the table,
it should use those macros for the offsets instead of hardcoding magic
constants in the relevant instructions. Furthermore, if you define those
macros in a common header, the table can do
.if .-__gnu_svml_dcos_data != MACRO_NAME
.err
.endif
at the start of each section of the table, so avoiding the need for
comments to mention the macro names and making sure the macros are
accurate. Then if someone changes part of the function implementation,
requiring replacing just one section of the table, you don't have problems
with quiet problems from not updating offsets - failing to update the
macros correctly will cause an immediate build failure.
--
Joseph S. Myers
joseph@codesourcery.com