This is the mail archive of the
mailing list for the glibc project.
Re: [RESEND] [PATCH] 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: Wed, 27 Feb 2019 17:58:46 +0000
- Subject: Re: [RESEND] [PATCH] PPC64: First in the series of patches implementing POWER8 vector math.
- References: <mbadK9r7XB9XyVASxb9oTqB0JO9qz9JKdC9mx1hUwBGcmMy7upcWFTvWuWGecBaMT3o5duV5MBjyRTEsgrtcpGltovJXQSJPH1rtECFMW-Yemail@example.com>
On Wed, 27 Feb 2019, GT wrote:
> 3. A new file, vec_finite_alias.c is a workaround until the vector
> log function is implemented. It is needed so that libmvec_nonshared.a
> is built. Without it, compiling against the newly-built glibc will
> fail due to its being missing.
It's inappropriate for this file to contain any log functions or
references. Presumably an empty file should suffice until a function
handled in bits/math-finite.h is added.
> 5. GCC has no vectorizing support for PPC64. The openmp pragmas
> are ignored and only scalar cosine calls generated. Exactly as when
> libmvec doesn't exist.
I don't see any evidence that the ABI has yet been agreed by all relevant
> 6. The executables created to test against new glibc installation
> required a workaround. x86_64 also did when I tried to compile the
> same test. The test is a modification of Example #1 at
> <https://sourceware.org/glibc/wiki/libmvec>. The only change initially
> is a replacement of the call to cos () with one to the vector version
> _ZGVbN2v_cos (). Compilation fails due to function without a
That completely defeats the point of such a test which is to verify that
an actual vectorized call works with the actual header you are adding -
not to repeat the verification of manual _Z* calls which is already
adequately done by the glibc testsuite. That means you need to have a
compiler which implements this vector ABI. If suitable GCC patches are
posted to gcc-patches with the stated intent of applying them to GCC trunk
after GCC 9 has branched, you could use those for testing the glibc
changes (although I think we should avoid merging the changes into glibc
until the relevant support is in GCC and you can name the corresponding
GCC version in the NEWS entry - note that GCC 9 should branch well before
the next glibc release freeze).
Joseph S. Myers