| Message ID | 20210408085827.5369-1-szabolcs.nagy@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | [COMMITTED] arm: update libm test ulps | expand |
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 ... > --- > sysdeps/arm/libm-test-ulps | 50 +++++++++++++++++++------------------- > 1 file changed, 25 insertions(+), 25 deletions(-) > > diff --git a/sysdeps/arm/libm-test-ulps b/sysdeps/arm/libm-test-ulps > index cdb635ee3d..f7e6046da4 100644 > --- a/sysdeps/arm/libm-test-ulps > +++ b/sysdeps/arm/libm-test-ulps > @@ -851,35 +851,35 @@ double: 1 > > Function: "j0": > double: 2 > -float: 8 > +float: 9 > > Function: "j0_downward": > -double: 2 > -float: 4 > +double: 5 > +float: 9 [snip]
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.
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.
On Tue, 13 Apr 2021, Adhemerval Zanella via Libc-alpha wrote: > 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. And for some of the higher ulps values it might be good to improve the precision, which suggests having at least per-format if not per-architecture empirical bounds for each function.
diff --git a/sysdeps/arm/libm-test-ulps b/sysdeps/arm/libm-test-ulps index cdb635ee3d..f7e6046da4 100644 --- a/sysdeps/arm/libm-test-ulps +++ b/sysdeps/arm/libm-test-ulps @@ -851,35 +851,35 @@ double: 1 Function: "j0": double: 2 -float: 8 +float: 9 Function: "j0_downward": -double: 2 -float: 4 +double: 5 +float: 9 Function: "j0_towardzero": -double: 4 -float: 5 +double: 6 +float: 9 Function: "j0_upward": -double: 4 -float: 5 +double: 9 +float: 9 Function: "j1": -double: 2 +double: 4 float: 9 Function: "j1_downward": -double: 3 -float: 5 +double: 5 +float: 8 Function: "j1_towardzero": -double: 3 -float: 2 +double: 4 +float: 8 Function: "j1_upward": -double: 3 -float: 5 +double: 9 +float: 9 Function: "jn": double: 4 @@ -1074,7 +1074,7 @@ double: 9 float: 8 Function: "tgamma_downward": -double: 8 +double: 9 float: 7 Function: "tgamma_towardzero": @@ -1087,35 +1087,35 @@ float: 8 Function: "y0": double: 3 -float: 8 +float: 9 Function: "y0_downward": double: 3 -float: 6 +float: 9 Function: "y0_towardzero": -double: 3 -float: 3 +double: 4 +float: 9 Function: "y0_upward": double: 3 -float: 6 +float: 9 Function: "y1": double: 3 -float: 2 +float: 9 Function: "y1_downward": -double: 3 -float: 2 +double: 6 +float: 9 Function: "y1_towardzero": double: 3 -float: 2 +float: 9 Function: "y1_upward": double: 7 -float: 2 +float: 9 Function: "yn": double: 3