On 4/21/23 22:43, Mikael Morin wrote:
Hello,
--- gcc/gimple-range-op.cc.jj 2023-04-21 17:09:48.250367999 +0200
+++ gcc/gimple-range-op.cc 2023-04-21 18:37:26.048325391 +0200
@@ -439,20 +436,38 @@ public:
r.set_varying (type);
return true;
}
+
// Results outsid
've merged your work with mine and am retesting. I have also swapped
the lb/ub per Mikael's comment downthread.
Should we adjust the range by say 50 ulps in either direction, and do
your target hook as a follow-up?
AldyFrom 065b8a1c1ec582eb3445ddb7f87ce9adc74394db Mon Sep 17 00:00:
On 4/21/23 08:52, Jakub Jelinek wrote:
On Thu, Apr 20, 2023 at 09:14:10PM -0400, Siddhesh Poyarekar wrote:
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't be
exhau
On 4/24/23 10:05, Siddhesh Poyarekar wrote:
On 2023-04-24 12:03, Jakub Jelinek wrote:
On Thu, Apr 20, 2023 at 01:57:55PM -0400, Siddhesh Poyarekar wrote:
Similarly for other functions which have other ranges, perhaps not
with so
nice round numbers. Say asin has [-pi/2, pi/2] range, those nu
On Mon, Apr 24, 2023 at 12:05:43PM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-24 12:03, Jakub Jelinek wrote:
> > On Thu, Apr 20, 2023 at 01:57:55PM -0400, Siddhesh Poyarekar wrote:
> > > > Similarly for other functions which have other ranges, perhaps not with
> > > > so
> > > > nice round numb
On 2023-04-24 12:03, Jakub Jelinek wrote:
On Thu, Apr 20, 2023 at 01:57:55PM -0400, Siddhesh Poyarekar wrote:
Similarly for other functions which have other ranges, perhaps not with so
nice round numbers. Say asin has [-pi/2, pi/2] range, those numbers aren't
exactly representable, but is it an
On Thu, Apr 20, 2023 at 01:57:55PM -0400, Siddhesh Poyarekar wrote:
> > Similarly for other functions which have other ranges, perhaps not with so
> > nice round numbers. Say asin has [-pi/2, pi/2] range, those numbers aren't
> > exactly representable, but is it any worse to round those values to
On Fri, Apr 21, 2023 at 10:43:44PM +0200, Mikael Morin wrote:
> Hello,
>
> > --- gcc/gimple-range-op.cc.jj 2023-04-21 17:09:48.250367999 +0200
> > +++ gcc/gimple-range-op.cc 2023-04-21 18:37:26.048325391 +0200
> > @@ -439,20 +436,38 @@ public:
> > r.set_varying (type);
> > return tr
Hello,
--- gcc/gimple-range-op.cc.jj 2023-04-21 17:09:48.250367999 +0200
+++ gcc/gimple-range-op.cc 2023-04-21 18:37:26.048325391 +0200
@@ -439,20 +436,38 @@ public:
r.set_varying (type);
return true;
}
+
// Results outside of [-1.0, +1.0] are impossible.
On Thu, Apr 20, 2023 at 02:59:35PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Thanks for working on this. Though expectedly here we are running
> again into the discussions we had in November about math properties of the
> functions vs. numeric properties in their implementations, how big maxim
On 2023-04-21 02:52, Jakub Jelinek wrote:
On Thu, Apr 20, 2023 at 09:14:10PM -0400, Siddhesh Poyarekar wrote:
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't be
exhau
On Thu, Apr 20, 2023 at 09:14:10PM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
> > For bounds that aren't representable, one could get error bounds from
> > libm-test-ulps data in glibc, although I reckon those won't be
> > exhaustive. From a quick peek at the
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't be
exhaustive. From a quick peek at the sin/cos data, the arc target seems
to be among the worst performers at about
On 2023-04-20 11:52, Jakub Jelinek wrote:
Why? Unless an implementation guarantees <= 0.5ulps errors, it can be one
or more ulps off, why is an error at or near 1.0 or -1.0 error any worse
than similar errors for other values?
In a general sense, maybe not, but in the sense of breaching the bo
On Thu, Apr 20, 2023 at 11:22:24AM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 10:02, Jakub Jelinek wrote:
> > On x86_64-linux with glibc 2.35, I see
> > for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD
> > DOWNWARD TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o /tmp/sinc
On 2023-04-20 10:02, Jakub Jelinek wrote:
On x86_64-linux with glibc 2.35, I see
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD
TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o /tmp/sincos{,.c} -lm;
/tmp/sincos || echo $i $j; done; done
Aborted (core dumped)
FLOAT
On Thu, Apr 20, 2023 at 04:02:02PM +0200, Jakub Jelinek via Gcc-patches wrote:
> So, I wrote following test.
Slightly adjusted to see more info:
x86_64-linux glibc 2.35:
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD
TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o
On Thu, Apr 20, 2023 at 09:17:10AM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
> > > +r.set (type, dconstm1, dconst1);
> >
> > See above, are we sure we can use [-1., 1.] range safely, or should that be
> > [-1.-Nulps, 1.+Nulps] for some kind of
On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
+r.set (type, dconstm1, dconst1);
See above, are we sure we can use [-1., 1.] range safely, or should that be
[-1.-Nulps, 1.+Nulps] for some kind of expected worse error margin of the
implementation? And ditto for -frounding-math, s
On Tue, Apr 18, 2023 at 03:12:50PM +0200, Aldy Hernandez wrote:
> [I don't know why I keep poking at floats. I must really like the pain.
> Jakub, are you OK with this patch for trunk?]
Thanks for working on this. Though expectedly here we are running
again into the discussions we had in Novembe
[I don't know why I keep poking at floats. I must really like the pain.
Jakub, are you OK with this patch for trunk?]
This is the range-op entry for sin/cos. It is meant to serve as an
example of what we can do for glibc math functions. It is by no means
exhaustive, just a stub to restrict the
21 matches
Mail list logo
