This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RESEND] [PATCH 1/12] PPC64: First in the series of patches implementing POWER8 vector math.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: GT <tnggil at protonmail dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 7 Mar 2019 19:13:02 +0000
- Subject: Re: [RESEND] [PATCH 1/12] PPC64: First in the series of patches implementing POWER8 vector math.
- References: <SLqh7MJvtXAa1Y5dfAS32jhZvA2XNtQLmNWcAyggITb-D0YPGLXvJ34fDpGxEIP8AsVlLcHx-V3d50_rrM5M2czbrxmWDtdvKV5bkTODvjY=@protonmail.com>
On Wed, 6 Mar 2019, GT wrote:
> 1. Removed the powerpc specific bits/math-vector.h file. With that gone
> I believe the patches can go into glibc master, as opposed to a branch.
> There is now no API for compilers to possibly produce erroneously
> vectorized calls to the SIMD math functions. That makes these functions
> totally inert until GCC comes along and needs to test its new PPC64
> autovectorization. Then, a PPC specific bits/math-vector.h will be added
> back into glibc.
The patch is still providing new ABIs (exported at public symbol versions)
and we don't yet have confirmation that the ABIs in question are the right
ones.
Compare the approach taken for Y2038 fixes, where many preparatory patches
going into glibc are adding function variants for 64-bit time_t and using
those internally - but none of the new symbols are actually being exported
(assigned symbol versions) until we're ready to support _TIME_BITS=64 as
an API across glibc. The libmvec case is different - there's no fixed set
of functions that needs to be supported, so adding a single function on
its own can be OK - but there's still the matter of establishing enough
confidence that the ABI is the right one (for example, with a
POWER-specific ABI document, signed off by appropriate people, that you
can reference in the commit message).
> 4. Changed patch subject line to now include m/n sequence indicator.
Could you also use the "git format-patch -v" convention for distinguishing
the version of the patch series? So if it's version 10 (I haven't counted
how many there have been), it would be "[PATCH v10 1/12]", for example (no
"[RESEND]", please).
--
Joseph S. Myers
joseph@codesourcery.com