Message ID | 20200820183700.115087-1-msc@linux.ibm.com |
---|---|
State | Superseded |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 638E83844027; Thu, 20 Aug 2020 18:37:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 638E83844027 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1597948632; bh=1cmURgT3RDUMF4sXSzqNX1opvP8gNuhLAjIIPoPrK0Q=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=cKsSBnsW6OU2OsdFfRamgZQVUvnqEcdLBVf89H0+hrbxlAG0ocaYa2k9vdbrEkUu6 7+uPDIjU6KjYESqmF3cB0SnbUZwq5lMZ+247hmaNhNrWPZ1wK2rY3eWj+sAze+vtTw oqYAx6MefkvOMBGaBPEgyMtNm2YZqeZWR02l8qsE= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 789533857C7E for <libc-alpha@sourceware.org>; Thu, 20 Aug 2020 18:37:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 789533857C7E Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07KIVxrw046794 for <libc-alpha@sourceware.org>; Thu, 20 Aug 2020 14:37:08 -0400 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com with ESMTP id 3313kyxrrb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <libc-alpha@sourceware.org>; Thu, 20 Aug 2020 14:37:08 -0400 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 07KIYqUC032498 for <libc-alpha@sourceware.org>; Thu, 20 Aug 2020 18:37:03 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma01wdc.us.ibm.com with ESMTP id 3304tkx8n0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <libc-alpha@sourceware.org>; Thu, 20 Aug 2020 18:37:03 +0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 07KIb2i953608726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Aug 2020 18:37:02 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6BBEBC605A; Thu, 20 Aug 2020 18:37:02 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E0C9AC605B; Thu, 20 Aug 2020 18:37:01 +0000 (GMT) Received: from localhost (unknown [9.85.146.58]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 20 Aug 2020 18:37:01 +0000 (GMT) To: libc-alpha@sourceware.org Subject: [PATCH] Update powerpc libm-test-ulps Date: Thu, 20 Aug 2020 15:37:00 -0300 Message-Id: <20200820183700.115087-1-msc@linux.ibm.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-20_03:2020-08-19, 2020-08-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 impostorscore=0 adultscore=0 bulkscore=0 clxscore=1015 mlxlogscore=708 malwarescore=0 suspectscore=1 phishscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008200146 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Matheus Castanho via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Matheus Castanho <msc@linux.ibm.com> Cc: tuliom@linux.ibm.com Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
Update powerpc libm-test-ulps
|
|
Commit Message
Matheus Castanho
Aug. 20, 2020, 6:37 p.m. UTC
Before this patch, the following tests were failing: ppc and ppc64: FAIL: math/test-ldouble-j0 ppc64le: FAIL: math/test-ibm128-j0 --- sysdeps/powerpc/fpu/libm-test-ulps | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On 8/20/20 2:37 PM, Matheus Castanho via Libc-alpha wrote: > Before this patch, the following tests were failing: > > ppc and ppc64: > FAIL: math/test-ldouble-j0 > > ppc64le: > FAIL: math/test-ibm128-j0 > --- > sysdeps/powerpc/fpu/libm-test-ulps | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sysdeps/powerpc/fpu/libm-test-ulps b/sysdeps/powerpc/fpu/libm-test-ulps > index cd2a5fed45..0b82c3f107 100644 > --- a/sysdeps/powerpc/fpu/libm-test-ulps > +++ b/sysdeps/powerpc/fpu/libm-test-ulps > @@ -1317,13 +1317,13 @@ Function: "j0_downward": > double: 2 > float: 4 > float128: 4 > -ldouble: 11 > +ldouble: 12 > > Function: "j0_towardzero": > double: 5 > float: 6 > float128: 2 > -ldouble: 8 > +ldouble: 16 We should not have ULPs higher than 9. I see Adhemerval added some 11 ULPs here for cexp. We should be able to achieve <= 9 ULPs on these algorithms, otherwise there are compiler problems that need fixing? > Function: "j0_upward": > double: 4 >
On 20/08/2020 15:39, Carlos O'Donell wrote: > On 8/20/20 2:37 PM, Matheus Castanho via Libc-alpha wrote: >> Before this patch, the following tests were failing: >> >> ppc and ppc64: >> FAIL: math/test-ldouble-j0 >> >> ppc64le: >> FAIL: math/test-ibm128-j0 >> --- >> sysdeps/powerpc/fpu/libm-test-ulps | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/sysdeps/powerpc/fpu/libm-test-ulps b/sysdeps/powerpc/fpu/libm-test-ulps >> index cd2a5fed45..0b82c3f107 100644 >> --- a/sysdeps/powerpc/fpu/libm-test-ulps >> +++ b/sysdeps/powerpc/fpu/libm-test-ulps >> @@ -1317,13 +1317,13 @@ Function: "j0_downward": >> double: 2 >> float: 4 >> float128: 4 >> -ldouble: 11 >> +ldouble: 12 >> >> Function: "j0_towardzero": >> double: 5 >> float: 6 >> float128: 2 >> -ldouble: 8 >> +ldouble: 16 > > We should not have ULPs higher than 9. > > I see Adhemerval added some 11 ULPs here for cexp. > > We should be able to achieve <= 9 ULPs on these algorithms, otherwise there are > compiler problems that need fixing? We are more forgiving for IBM long double due its inherent precision issues: math/libm-test-support.c 228 if (testing_ibm128) 229 /* The documented accuracy of IBM long double division is 3ulp 230 (see libgcc/config/rs6000/ibm-ldouble-format), so do not 231 require better accuracy for libm functions that are exactly 232 defined for other formats. */ 233 max_valid_error = exact ? 3 : 16; 234 else 235 max_valid_error = exact ? 0 : 9; And jN implementation also has low precision for some inputs. With both constraints I think 16ulps should be ok.
Dear Carlos, > We should be able to achieve <= 9 ULPs on these algorithms, otherwise there are > compiler problems that need fixing? we are far from <= 9 ULPS for j0,j1,y0,y1, even in binary32. See https://members.loria.fr/PZimmermann/papers/accuracy.pdf. Paul
Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes: > On 20/08/2020 15:39, Carlos O'Donell wrote: >> On 8/20/20 2:37 PM, Matheus Castanho via Libc-alpha wrote: >>> Before this patch, the following tests were failing: >>> >>> ppc and ppc64: >>> FAIL: math/test-ldouble-j0 >>> >>> ppc64le: >>> FAIL: math/test-ibm128-j0 >>> --- >>> sysdeps/powerpc/fpu/libm-test-ulps | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/sysdeps/powerpc/fpu/libm-test-ulps b/sysdeps/powerpc/fpu/libm-test-ulps >>> index cd2a5fed45..0b82c3f107 100644 >>> --- a/sysdeps/powerpc/fpu/libm-test-ulps >>> +++ b/sysdeps/powerpc/fpu/libm-test-ulps >>> @@ -1317,13 +1317,13 @@ Function: "j0_downward": >>> double: 2 >>> float: 4 >>> float128: 4 >>> -ldouble: 11 >>> +ldouble: 12 >>> >>> Function: "j0_towardzero": >>> double: 5 >>> float: 6 >>> float128: 2 >>> -ldouble: 8 >>> +ldouble: 16 >> >> We should not have ULPs higher than 9. >> >> I see Adhemerval added some 11 ULPs here for cexp. >> >> We should be able to achieve <= 9 ULPs on these algorithms, otherwise there are >> compiler problems that need fixing? > > We are more forgiving for IBM long double due its inherent precision issues: > > math/libm-test-support.c > > 228 if (testing_ibm128) > 229 /* The documented accuracy of IBM long double division is 3ulp > 230 (see libgcc/config/rs6000/ibm-ldouble-format), so do not > 231 require better accuracy for libm functions that are exactly > 232 defined for other formats. */ > 233 max_valid_error = exact ? 3 : 16; > 234 else > 235 max_valid_error = exact ? 0 : 9; > > And jN implementation also has low precision for some inputs. With both constraints > I think 16ulps should be ok. There is also a loss of precision with different rounding modes in libgcc. There are currently 30 entries for ibm128 with ULP between 10 and 16 (without counting this patch). Maybe some of these should actually be marked as xfail-rounding:ibm128-libgcc instead. The only way to validate this is by compiling glibc with a libgcc that has a patch from Joseph. I have an up-to-date version of that patch in https://github.com/tuliom/gcc/commit/ca42479cae3c2b56651c3e97bb5eeaf24ca4bb61
On 8/20/20 3:44 PM, Tulio Magno Quites Machado Filho wrote: > Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes: > >> On 20/08/2020 15:39, Carlos O'Donell wrote: >>> On 8/20/20 2:37 PM, Matheus Castanho via Libc-alpha wrote: >>>> Before this patch, the following tests were failing: >>>> >>>> ppc and ppc64: >>>> FAIL: math/test-ldouble-j0 >>>> >>>> ppc64le: >>>> FAIL: math/test-ibm128-j0 >>>> --- >>>> sysdeps/powerpc/fpu/libm-test-ulps | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/sysdeps/powerpc/fpu/libm-test-ulps b/sysdeps/powerpc/fpu/libm-test-ulps >>>> index cd2a5fed45..0b82c3f107 100644 >>>> --- a/sysdeps/powerpc/fpu/libm-test-ulps >>>> +++ b/sysdeps/powerpc/fpu/libm-test-ulps >>>> @@ -1317,13 +1317,13 @@ Function: "j0_downward": >>>> double: 2 >>>> float: 4 >>>> float128: 4 >>>> -ldouble: 11 >>>> +ldouble: 12 >>>> >>>> Function: "j0_towardzero": >>>> double: 5 >>>> float: 6 >>>> float128: 2 >>>> -ldouble: 8 >>>> +ldouble: 16 >>> >>> We should not have ULPs higher than 9. >>> >>> I see Adhemerval added some 11 ULPs here for cexp. >>> >>> We should be able to achieve <= 9 ULPs on these algorithms, otherwise there are >>> compiler problems that need fixing? >> >> We are more forgiving for IBM long double due its inherent precision issues: >> >> math/libm-test-support.c >> >> 228 if (testing_ibm128) >> 229 /* The documented accuracy of IBM long double division is 3ulp >> 230 (see libgcc/config/rs6000/ibm-ldouble-format), so do not >> 231 require better accuracy for libm functions that are exactly >> 232 defined for other formats. */ >> 233 max_valid_error = exact ? 3 : 16; >> 234 else >> 235 max_valid_error = exact ? 0 : 9; Thanks. I didn't know that. >> >> And jN implementation also has low precision for some inputs. With both constraints >> I think 16ulps should be ok. > > There is also a loss of precision with different rounding modes in libgcc. > > There are currently 30 entries for ibm128 with ULP between 10 and 16 (without > counting this patch). Maybe some of these should actually be marked as > xfail-rounding:ibm128-libgcc instead. If the loss of precision is due to the implementation then it seems like using an XFAIL is not an accurate representation of the state. > The only way to validate this is by compiling glibc with a libgcc that has a > patch from Joseph. I have an up-to-date version of that patch in > https://github.com/tuliom/gcc/commit/ca42479cae3c2b56651c3e97bb5eeaf24ca4bb61 Interesting patch, it looks similar to what we do in glibc for some of the libm functions.
On 8/20/20 6:25 PM, Carlos O'Donell wrote: > On 8/20/20 3:44 PM, Tulio Magno Quites Machado Filho wrote: >> Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes: >> >>> On 20/08/2020 15:39, Carlos O'Donell wrote: >>>> On 8/20/20 2:37 PM, Matheus Castanho via Libc-alpha wrote: >>>>> Before this patch, the following tests were failing: >>>>> >>>>> ppc and ppc64: >>>>> FAIL: math/test-ldouble-j0 >>>>> >>>>> ppc64le: >>>>> FAIL: math/test-ibm128-j0 >>>>> --- >>>>> sysdeps/powerpc/fpu/libm-test-ulps | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/sysdeps/powerpc/fpu/libm-test-ulps b/sysdeps/powerpc/fpu/libm-test-ulps >>>>> index cd2a5fed45..0b82c3f107 100644 >>>>> --- a/sysdeps/powerpc/fpu/libm-test-ulps >>>>> +++ b/sysdeps/powerpc/fpu/libm-test-ulps >>>>> @@ -1317,13 +1317,13 @@ Function: "j0_downward": >>>>> double: 2 >>>>> float: 4 >>>>> float128: 4 >>>>> -ldouble: 11 >>>>> +ldouble: 12 >>>>> >>>>> Function: "j0_towardzero": >>>>> double: 5 >>>>> float: 6 >>>>> float128: 2 >>>>> -ldouble: 8 >>>>> +ldouble: 16 >>>> >>>> We should not have ULPs higher than 9. >>>> >>>> I see Adhemerval added some 11 ULPs here for cexp. >>>> >>>> We should be able to achieve <= 9 ULPs on these algorithms, otherwise there are >>>> compiler problems that need fixing? >>> >>> We are more forgiving for IBM long double due its inherent precision issues: >>> >>> math/libm-test-support.c >>> >>> 228 if (testing_ibm128) >>> 229 /* The documented accuracy of IBM long double division is 3ulp >>> 230 (see libgcc/config/rs6000/ibm-ldouble-format), so do not >>> 231 require better accuracy for libm functions that are exactly >>> 232 defined for other formats. */ >>> 233 max_valid_error = exact ? 3 : 16; >>> 234 else >>> 235 max_valid_error = exact ? 0 : 9; > > Thanks. I didn't know that. > >>> >>> And jN implementation also has low precision for some inputs. With both constraints >>> I think 16ulps should be ok. >> >> There is also a loss of precision with different rounding modes in libgcc. >> >> There are currently 30 entries for ibm128 with ULP between 10 and 16 (without >> counting this patch). Maybe some of these should actually be marked as >> xfail-rounding:ibm128-libgcc instead. > > If the loss of precision is due to the implementation then it seems like using > an XFAIL is not an accurate representation of the state. > >> The only way to validate this is by compiling glibc with a libgcc that has a >> patch from Joseph. I have an up-to-date version of that patch in >> https://github.com/tuliom/gcc/commit/ca42479cae3c2b56651c3e97bb5eeaf24ca4bb61 > > Interesting patch, it looks similar to what we do in glibc for some of the > libm functions. > What do you think we should do in this case? Looks like with the libgcc patch Tulio mentioned we can actually calculate the correct ULPs for ibm128, but we would not be able to get that same precision when building with a regular GCC, which would still cause issues. So should we: 1. Use max precision ULPs calculated with the patched libgcc? This would probably require adding xfail-rounding:ibm128-libgcc to several entries in auto-libm-test-in to guarantee tests pass with regular GCC. 2. Do (1) only for entries that have ULPs higher than a threshold (say, 9 or 16)? 3. Apply the patch as-is? 4. Other? -- Matheus Castanho
Matheus Castanho via Libc-alpha <libc-alpha@sourceware.org> writes: > What do you think we should do in this case? Looks like with the libgcc > patch Tulio mentioned we can actually calculate the correct ULPs for > ibm128, but we would not be able to get that same precision when > building with a regular GCC, which would still cause issues. > > So should we: > 1. Use max precision ULPs calculated with the patched libgcc? > This would probably require adding xfail-rounding:ibm128-libgcc to > several entries in auto-libm-test-in to guarantee tests pass with > regular GCC. I believe this is the best solution if the amount of tests marked as xfail is small, e.g. 100 out of ~8k from math/auto-libm-test-in. However, if a high percentage of tests are xfail'ed, then I think we should consider option 2. > 2. Do (1) only for entries that have ULPs higher than a threshold (say, > 9 or 16)? Likewise, if we're able to keep maximum ULPs at 9 without marking too many tests as xfail'ed, that's better. Per the contents of sysdeps/powerpc/fpu/libm-test-ulps, this should be possible and would not need have a greater max_valid_error for inexact functions just for ibm128.
On Mon, 31 Aug 2020, Tulio Magno Quites Machado Filho via Libc-alpha wrote: > > 2. Do (1) only for entries that have ULPs higher than a threshold (say, > > 9 or 16)? > > Likewise, if we're able to keep maximum ULPs at 9 without marking too many tests > as xfail'ed, that's better. > Per the contents of sysdeps/powerpc/fpu/libm-test-ulps, this should be possible > and would not need have a greater max_valid_error for inexact functions just > for ibm128. If the functions for different floating-point formats use similar algorithms, the error may be a multiple of the error for the basic arithmetic operations. Since the basic arithmetic operations for ldbl-128ibm are less accurate than for IEEE formats, it seems reasonable to allow larger errors for libm functions for that format as well. Ideally the errors would be smaller than they are for some functions with larger errors, but that might require algorithmic improvements. The existing bounds of 9 or 16 ulps are empirical, based on what's seen with functions where the issue is simply the accumulation of lots of separate errors rather than algorithms with inherent numerical problems.
Hi, We're seeing these powerpc test failures in our Fedora testing. Is it possible to submit the original ulps patch and resolve the other concerns going forward? Thank you, Patsy On Mon, Aug 31, 2020 at 1:44 PM Tulio Magno Quites Machado Filho via Libc-alpha <libc-alpha@sourceware.org> wrote: > Matheus Castanho via Libc-alpha <libc-alpha@sourceware.org> writes: > > > What do you think we should do in this case? Looks like with the libgcc > > patch Tulio mentioned we can actually calculate the correct ULPs for > > ibm128, but we would not be able to get that same precision when > > building with a regular GCC, which would still cause issues. > > > > So should we: > > 1. Use max precision ULPs calculated with the patched libgcc? > > This would probably require adding xfail-rounding:ibm128-libgcc to > > several entries in auto-libm-test-in to guarantee tests pass with > > regular GCC. > > I believe this is the best solution if the amount of tests marked as xfail > is > small, e.g. 100 out of ~8k from math/auto-libm-test-in. > However, if a high percentage of tests are xfail'ed, then I think we should > consider option 2. > > > 2. Do (1) only for entries that have ULPs higher than a threshold (say, > > 9 or 16)? > > Likewise, if we're able to keep maximum ULPs at 9 without marking too many > tests > as xfail'ed, that's better. > Per the contents of sysdeps/powerpc/fpu/libm-test-ulps, this should be > possible > and would not need have a greater max_valid_error for inexact functions > just > for ibm128. > > -- > Tulio Magno > >
diff --git a/sysdeps/powerpc/fpu/libm-test-ulps b/sysdeps/powerpc/fpu/libm-test-ulps index cd2a5fed45..0b82c3f107 100644 --- a/sysdeps/powerpc/fpu/libm-test-ulps +++ b/sysdeps/powerpc/fpu/libm-test-ulps @@ -1317,13 +1317,13 @@ Function: "j0_downward": double: 2 float: 4 float128: 4 -ldouble: 11 +ldouble: 12 Function: "j0_towardzero": double: 5 float: 6 float128: 2 -ldouble: 8 +ldouble: 16 Function: "j0_upward": double: 4