> 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
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
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
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
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
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
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
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
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
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
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
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.
>
> Jakub
From 759bcd4b4b6f70fcec045b24fb6874aaca989549 Mon Sep 17 00:00:00 2001
F
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
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,
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 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
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
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
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
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,
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
21 matches
Mail list logo
