unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Tulio Magno Quites Machado Filho <tuliom@ascii.art.br>
To: Shawn Landden <shawn@git.icu>, libc-alpha@sourceware.org
Subject: Re: [PATCH 2/2] PPC64: Add libmvec SIMD double-precision natural exponent function.
Date: Fri, 24 May 2019 18:41:32 -0300	[thread overview]
Message-ID: <875zpzmsxf.fsf@linux.ibm.com> (raw)
In-Reply-To: <20190512032812.22021-2-shawn@git.icu>

Hi Shawn,

We also have a couple of small issues in this patch as well as 2 testcases
failing.

I'm also raising a concern here based on the copyright of one of the files.
I don't know how to proceed and we'll need help from the project stewards.


Shawn Landden <shawn@git.icu> writes:

> [BZ #24209]
>
> Passes all tests.
>
> Unlike other libmvec functions, this sets the onderflow and overflow bits.

s/onderflow/underflow/

> The caller can check these flags, and possibly re-run the calculations with
> scalar expf to figure out what is causing the overflow or underflow.
>
> The special-case path is not vectorized, and performs much woorse than
> the scalar code.
> Normalized data: 1 to 2^32 converted to double
> Running 20 times over 32MiB
> vector: mean 563.807107 MiB/s (sd 0.390922)
> scalar: mean 226.527824 MiB/s (sd 0.077406)
>
> Random data:
> vector: mean 80.175986 MiB/s (sd 1.110948)
> scalar: mean 244.738130 MiB/s (sd 0.029561)

After applying this patch, I started seeing many errors from
math/test-double-vlen2-exp, e.g.:

testing double (vector length 2)
Failure: Test: exp_vlen2 (qNaN)
Result:
 is:          inf   inf
 should be:  qNaN
Failure: Test: exp_vlen2 (-qNaN)
Result:
 is:          0.0000000000000000e+00   0x0.0000000000000p+0
 should be:  qNaN
Failure: Test: exp_vlen2 (sNaN)
Result:
 is:          inf   inf
 should be:  qNaN
Failure: Test: exp_vlen2 (-sNaN)
Result:
 is:          0.0000000000000000e+00   0x0.0000000000000p+0
 should be:  qNaN
Failure: Test: exp_vlen2 (-0)
Result:
 is:          1.1000000000000001e+00   0x1.199999999999ap+0
 should be:   1.0000000000000000e+00   0x1.0000000000000p+0
 difference:  1.0000000000000009e-01   0x1.99999999999a0p-4
 ulp       :  450359962737050.0000
 max.ulp   :  0.0000
...

I've seen it both with gcc 8.3 and 9.1.

> 2019-05-11 Shawn Landden <shawn@git.icu>
>         * NEWS: Noted the addition of PPC64 vector exp function.

Likewise, this ChangeLog entry needs rework.
Previous comments apply here too.

>         * sysdeps/powerpc/powerpc64/fpu/multiarch/(math_config.h)->(math_config_dbl.h):
> 	Renamed, and modified for exp.

Please use this instead:

	* sysdeps/powerpc/powerpc64/fpu/multiarch/math_config.h: Renamed as...
	* sysdeps/powerpc/powerpc64/fpu/multiarch/math_config_dbl.h: ... and
	modified for exp.

> diff --git a/sysdeps/powerpc/powerpc64/fpu/multiarch/math_config.h b/sysdeps/powerpc/powerpc64/fpu/multiarch/math_config_dbl.h
> similarity index 94%
> rename from sysdeps/powerpc/powerpc64/fpu/multiarch/math_config.h
> rename to sysdeps/powerpc/powerpc64/fpu/multiarch/math_config_dbl.h
> index bd37906ecb..039ff6adeb 100644
> --- a/sysdeps/powerpc/powerpc64/fpu/multiarch/math_config.h
> +++ b/sysdeps/powerpc/powerpc64/fpu/multiarch/math_config_dbl.h
> @@ -17,15 +17,20 @@
>     <http://www.gnu.org/licenses/>.  */
>  
>  #ifndef _MATH_CONFIG_H
>  #define _MATH_CONFIG_H
>  
> +#ifndef EXP_USE_TOINT_NARROW
> +#define EXP_USE_TOINT_NARROW 0
> +#endif

When is EXP_USE_TOINT_NARROW != 0?
We need source code comments explaining what this macro is doing

> diff --git a/sysdeps/powerpc/powerpc64/fpu/multiarch/vec_d_exp2_vsx.c b/sysdeps/powerpc/powerpc64/fpu/multiarch/vec_d_exp2_vsx.c
> new file mode 100644
> index 0000000000..6a9dfb4492
> --- /dev/null
> +++ b/sysdeps/powerpc/powerpc64/fpu/multiarch/vec_d_exp2_vsx.c
>...
> +
> +/* Top 12 bits of a double (sign and exponent bits).  */
> +static inline uint32_t top12(double x)

Wrong coding style:

static inline uint32_t
top12 (double x)

> +{
> +	return asuint64(x) >> 52;

The indentation style changed from this line forward.

> diff --git a/sysdeps/powerpc/powerpc64/fpu/multiarch/vec_d_exp_data.c b/sysdeps/powerpc/powerpc64/fpu/multiarch/vec_d_exp_data.c
> new file mode 100644
> index 0000000000..650fdee75f
> --- /dev/null
> +++ b/sysdeps/powerpc/powerpc64/fpu/multiarch/vec_d_exp_data.c
> @@ -0,0 +1,200 @@
> +/*
> + * Shared data between exp, exp2 and pow.
> + *
> + * Copyright (c) 2018, Arm Limited.
> + * SPDX-License-Identifier: MIT
> + */

Do you have the approval from the copyright holder to contribute this file?

I don't know if glibc can accept this file as-is.
We need to clarify this.

> diff --git a/sysdeps/unix/sysv/linux/powerpc/powerpc64/libmvec.abilist b/sysdeps/unix/sysv/linux/powerpc/powerpc64/libmvec.abilist
> index 63770c8da3..5e662ffa70 100644
> --- a/sysdeps/unix/sysv/linux/powerpc/powerpc64/libmvec.abilist
> +++ b/sysdeps/unix/sysv/linux/powerpc/powerpc64/libmvec.abilist
> @@ -5,5 +5,6 @@ GLIBC_2.30 _ZGVbN2vvv_sincos F
>  GLIBC_2.30 _ZGVbN4v_cosf F
>  GLIBC_2.30 _ZGVbN4v_logf F
>  GLIBC_2.30 _ZGVbN4v_sinf F
>  GLIBC_2.30 _ZGVbN4vvv_sincosf F
>  GLIBC_2.30 _ZGVbN4v_expf F
> +GLIBC_2.30 _ZGVbN2v_exp F

They have to be properly sorted, unless we get an error from
mathvec/check-abi-libmvec:

@@ -1,0 +2 @@ GLIBC_2.30 _ZGVbN2v_cos F
+GLIBC_2.30 _ZGVbN2v_exp F
@@ -5,0 +7 @@ GLIBC_2.30 _ZGVbN4v_cosf F
+GLIBC_2.30 _ZGVbN4v_expf F
@@ -9,2 +10,0 @@ GLIBC_2.30 _ZGVbN4vvv_sincosf F
-GLIBC_2.30 _ZGVbN4v_expf F
-GLIBC_2.30 _ZGVbN2v_exp F


-- 
Tulio Magno

  reply	other threads:[~2019-05-24 21:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-12  3:28 [PATCH 1/2] PPC64: Add libmvec SIMD single-precision natural exponent function Shawn Landden
2019-05-12  3:28 ` [PATCH 2/2] PPC64: Add libmvec SIMD double-precision " Shawn Landden
2019-05-24 21:41   ` Tulio Magno Quites Machado Filho [this message]
     [not found]     ` <CA+49okpEUryebPwnwJha-wJ49=w2qo5r_+JUWvCD-e495UDH5g@mail.gmail.com>
2019-05-24 22:25       ` Tulio Magno Quites Machado Filho
2019-05-24 20:04 ` [PATCH 1/2] PPC64: Add libmvec SIMD single-precision " Tulio Magno Quites Machado Filho
2019-05-27 17:47 ` [v2 " Shawn Landden
2019-05-27 17:47   ` [v2 2/2] PPC64: Add libmvec SIMD double-precision " Shawn Landden
2019-05-29 13:18     ` Tulio Magno Quites Machado Filho
2019-05-29 19:11       ` [v3 PATCH] " Shawn Landden
2019-05-29 19:12         ` Shawn Landden
2019-05-29 19:19           ` Florian Weimer
2019-06-04  2:43         ` Shawn Landden
2019-06-04 20:00         ` Tulio Magno Quites Machado Filho
2019-05-27 18:00   ` [v2 1/2] PPC64: Add libmvec SIMD single-precision " Shawn Landden
2019-05-28 18:20   ` Tulio Magno Quites Machado Filho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875zpzmsxf.fsf@linux.ibm.com \
    --to=tuliom@ascii.art.br \
    --cc=libc-alpha@sourceware.org \
    --cc=shawn@git.icu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).