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.
gcc/ChangeLog:
* gimple-range-op.cc (class cfn_sqrt): New.
(gimple_range_op_handler::maybe_builtin_call): Add cases f
On Thu, Nov 17, 2022 at 8:38 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Nov 17, 2022 at 06:59:45PM +, Joseph Myers wrote:
> > On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
> >
> > > So... is the optimization wrong? Are we not allowed to substitute
> > > that NAN if we kn
On 11/18/22 09:39, Richard Biener wrote:
On Thu, Nov 17, 2022 at 8:38 PM Jakub Jelinek via Gcc-patches
wrote:
On Thu, Nov 17, 2022 at 06:59:45PM +, Joseph Myers wrote:
On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
So... is the optimization wrong? Are we not allowed to s
On Fri, Nov 18, 2022 at 11:37:42AM +0100, Aldy Hernandez wrote:
> > Practically strictly
> > preserving IEEE exceptions is only important for a very small audience, and
> > for that even INEXACT will matter (but we still have -ftrapping-math
> > by default).
> > For that audience likely all constan
On 11/18/22 11:44, Jakub Jelinek wrote:
On Fri, Nov 18, 2022 at 11:37:42AM +0100, Aldy Hernandez wrote:
Practically strictly
preserving IEEE exceptions is only important for a very small audience, and
for that even INEXACT will matter (but we still have -ftrapping-math
by default).
For that a
I wonder if instead of disabling ranger altogether, we could disable code
changes (constant propagation, jump threading and simplify_using_ranges)?
Or does that sound like too much hassle?
It seems that some passes (instruction selection?) could benefit from
global ranges being available even if n
> Am 18.11.2022 um 11:44 schrieb Jakub Jelinek :
>
> On Fri, Nov 18, 2022 at 11:37:42AM +0100, Aldy Hernandez wrote:
>>> Practically strictly
>>> preserving IEEE exceptions is only important for a very small audience, and
>>> for that even INEXACT will matter (but we still have -ftrapping-math
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.
On Sun, Nov 13, 2022 at 9:39 PM Jakub Jelinek 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 op
On 11/14/22 00:45, Aldy Hernandez via Gcc-patches wrote:
On Sun, Nov 13, 2022 at 9:39 PM Jakub Jelinek 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 thi
On Mon, Nov 14, 2022 at 07:30:18AM -0700, Jeff Law via Gcc-patches wrote:
> 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 boun
On 11/14/22 07:35, Jakub Jelinek wrote:
On Mon, Nov 14, 2022 at 07:30:18AM -0700, Jeff Law via Gcc-patches wrote:
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
Huh...no argument from me.
Thanks.
Aldy
On Mon, Nov 14, 2022, 15:35 Jakub Jelinek wrote:
> On Mon, Nov 14, 2022 at 07:30:18AM -0700, Jeff Law via Gcc-patches wrote:
> > To Jakub's concern. I thought sqrt was treated like +-/* WRT accuracy
> > requirements by IEEE. ie, for any input there is
On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
> 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,
On Mon, Nov 14, 2022 at 09:55:29PM +, Joseph Myers wrote:
> On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
>
> > 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
The idea is that we'd collect ballpark estimates for roundtonearest and
> then estimates for the other 3 rounding modes, the former would be used
> without -frounding-math, max over all 4 rounding modes for -frounding-math
> as gcc will compute using mpfr always in round to nearest.
On 11/17/22 17:40, Aldy Hernandez wrote:
To go along with whatever magic we're gonna tack along to the
range-ops sqrt implementation, here is another revision addressing the
VARYING issue you pointed out.
A few things...
Instead of going through trees, I decided to call do_mpfr_arg1
directly
This may be DCE.
DOM uses ranger through simplify_using_ranges::fold_cond() to fold the
following conditional to false, because we know x_185 is a NAN:
x_185 = __builtin_sqrtf (-1.0e+0);
if (x_185 ord x_185)
I believe we can do that, because there are no user observable
effects. But DCE remove
On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
> So... is the optimization wrong? Are we not allowed to substitute
> that NAN if we know it's gonna happen? Should we also allow F F F F F
> in the test? Or something else?
This seems like the usual ambiguity about what transformation
On Thu, Nov 17, 2022 at 06:59:45PM +, Joseph Myers wrote:
> On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
>
> > So... is the optimization wrong? Are we not allowed to substitute
> > that NAN if we know it's gonna happen? Should we also allow F F F F F
> > in the test? Or someth
On Thu, 17 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Nov 17, 2022 at 06:59:45PM +, Joseph Myers wrote:
> > On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
> >
> > > So... is the optimization wrong? Are we not allowed to substitute
> > > that NAN if we know it's gonn
21 matches
Mail list logo