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.
next prev parent 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).