On 11/14/22 00:45, Aldy Hernandez via Gcc-patches wrote:
On Sun, Nov 13, 2022 at 9:39 PM Jakub Jelinek <ja...@redhat.com> wrote:
On Sun, Nov 13, 2022 at 09:05:53PM +0100, Aldy Hernandez wrote:
It seems SQRT is relatively straightforward, and it's something Jakub
wanted for this release.
Jakub, what do you think?
p.s. Too tired to think about op1_range.
That would be multiplication of the same value twice, i.e.
fop_mult with trio that has op1_op2 () == VREL_EQ?
But see below, as sqrt won't be always precise, we need to account for
some errors.
gcc/ChangeLog:
* gimple-range-op.cc (class cfn_sqrt): New.
(gimple_range_op_handler::maybe_builtin_call): Add cases for sqrt.
Yes, I'd like to see SQRT support in.
The only thing I'm worried is that unlike {+,-,*,/}, negation etc. typically
implemented in hardware or precise soft-float, sqrt is often implemented
in library using multiple floating point arithmetic functions. And different
implementations have different accuracy.
So, I wonder if we don't need to add a target hook where targets will be
able to provide upper bound on error for floating point functions for
different floating point modes and some way to signal unknown accuracy/can't
be trusted, in which case we would give up or return just the range for
VARYING.
Then, we could write some tests that say in a loop constructs random
floating point values (perhaps sanitized to be non-NAN), calls libm function
and the same mpfr one and return maximum error in ulps.
And then record those, initially for glibc and most common targets and
gradually maintainers could supply more.
If we add an infrastructure for that within a few days, then we could start
filling the details. One would hope that sqrt has < 10ulps accuracy if not
already the 0.5ulp one, but for various other functions I think it can be
I don't know what would possess me to think that sqrt would be easy
;-). Sure, I can sink a few days to flesh this out if you're willing
to review it.
To Jakub's concern. I thought sqrt was treated like +-/* WRT accuracy
requirements by IEEE. ie, for any input there is a well defined answer
for a confirming IEEE implementation. In fact, getting to that .5ulp
bound is a significant amount of the cost for a NR or Goldschmidt (or
hybrid) implementation if you've got a reasonable (say 12 or 14 bit)
estimator and high performance fmacs.
Jeff
