public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
	Carlos O'Donell <carlos@redhat.com>,
	Joseph Myers <joseph@codesourcery.com>
Subject: Re: [COMMITTED] arm: update libm test ulps
Date: Tue, 13 Apr 2021 12:01:01 -0300	[thread overview]
Message-ID: <6fd7e855-3de3-3044-d56e-14ca1f0cd717@linaro.org> (raw)
In-Reply-To: <20210413095214.GV23289@arm.com>



On 13/04/2021 06:52, Szabolcs Nagy wrote:
> The 04/11/2021 18:04, Vineet Gupta wrote:
>> On 4/8/21 1:58 AM, Szabolcs Nagy via Libc-alpha wrote:
>>> Updated after commits 9acda61d94acc5348c2330f2519a14d1a4a37e73
>>> and 43576de04afc6a0896a3ecc094e1581069a0652a.
>>
>> Is there a better way for this to be done at the time of original change 
>> other than running the tests on all affected architectures. arches 
>> always seem to be chasing these kind of changes ...
> 
> i think there are only small variations between targets for
> float and double, so the ulp error limits for those could be
> shared (unless a target has its own implementation with
> different quality requirement for some reason).
> 
> long double is more target specific. i think the tests could
> be organised such that each sysdeps/ieee754/* directory has
> its own ulp limits file and the target picks up the right one.
> 
> and libmvec needs target specific ulp limits.
> 
> i don't know how hard it would be to implement this.
> 

The math/libm-test-support.c imposes maximum ulp limits depending of 
the underling type:

 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 if I recall correctly there was a suggestion to consolidate and/or
remove the ulps file altogether and use the maximum valid error as the
threshold to report regressions.  The only drawback I see of moving
towards it is each architecture won't see if some change has degraded
the function precision.

But I tend to agree that using per-architecture ulp files do not add
much, since arch maintainer tend todig into the precision issues only
when it is higher the the tests threshold.

  reply	other threads:[~2021-04-13 15:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08  8:58 Szabolcs Nagy
2021-04-11 18:04 ` Vineet Gupta
2021-04-13  9:52   ` Szabolcs Nagy
2021-04-13 15:01     ` Adhemerval Zanella [this message]
2021-04-13 18:02       ` Joseph Myers

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

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

  git send-email \
    --in-reply-to=6fd7e855-3de3-3044-d56e-14ca1f0cd717@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=Vineet.Gupta1@synopsys.com \
    --cc=carlos@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=szabolcs.nagy@arm.com \
    /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).