This is the op1_range range-op entry for __builtin_signbit. It allows
us to wind back through a call to signbit.
For example, on the true side of if (__builtin_signbit(x_5) != 0) we
can crop down the range of x_5 to:
[frange] float [-Inf, -0.0 (-0x0.0p+0)] -NAN
Similarly on the false
The uses of finite_operands_p removed are guarded by a call to
finite_operands_p already.
gcc/ChangeLog:
* range-op-float.cc (foperator_lt::fold_range): Remove extra check
to finite_operands_p.
(foperator_le::fold_range): Same.
(foperator_gt::fold_range): Same.
gcc/ChangeLog:
* value-range-pretty-print.cc (vrange_printer::print_real_value):
Avoid printing INF and NAN twice.
---
gcc/value-range-pretty-print.cc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/value-range-pretty-print.cc
We recently agreed that setting a range of NAN should instead set
UNDEFINED for -ffinite-math-only. This patch makes that change to
frange::set_nan() directly. Also, calling frange::update_nan() will now
be a nop for !HONOR_NANS.
Doing this in the setters simplifies everywhere we set NANs, as
gcc/ChangeLog:
* range-op.cc (operator_cast::fold_range): Handle truncating casts
for nonzero masks.
---
gcc/range-op.cc | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 6fa27a8904e..df0735cb42a 100644
PR tree-optimization/107052
gcc/ChangeLog:
* gimple-range-op.cc (cfn_popcount::fold_range): Take into account
nonzero bit mask.
---
gcc/gimple-range-op.cc | 15 ---
gcc/testsuite/gcc.dg/tree-ssa/pr107052.c | 13 +
2 files
Track nonzero masks through a cast in range-ops.
We could also track through a truncating cast if the mask fits in the
outer type. I will do that as a follow-up patch because I already have
this patchset tested.
PR tree-optimization/107052
gcc/ChangeLog:
* range-op.cc
Track nonzero masks through a cast in range-ops.
We could also track through a truncating cast if the mask fits in the
outer type. I will do that as a follow-up patch because I already have
this patchset tested.
PR tree-optimization/107052
gcc/ChangeLog:
* range-op.cc
On Tue, Oct 4, 2022 at 5:42 PM Andrew MacLeod wrote:
>
>
> On 10/4/22 11:14, Aldy Hernandez wrote:
> > On Tue, Oct 4, 2022 at 4:34 PM Richard Biener
> > wrote:
> >>
> >>
> >>> Am 04.10.2022 um 16:30 schrieb Aldy Hernandez :
> >>>
>
The assert removed by this patch was there to keep users from passing
masks of incompatible types. The self tests are passing host wide
ints down (set_nonzero_bits (-1)), which seem to be 32 bits, whereas
some embedded targets have integer_type_node's of 16-bits. This is
causing problems in
On Tue, Oct 4, 2022 at 4:34 PM Richard Biener
wrote:
>
>
>
> > Am 04.10.2022 um 16:30 schrieb Aldy Hernandez :
> >
> > On Tue, Oct 4, 2022 at 3:27 PM Andrew MacLeod wrote:
> >>
> >>
> >>> On 10/4/22 08:13, Aldy Hernandez via Gcc-patche
On Tue, Oct 4, 2022 at 3:27 PM Andrew MacLeod wrote:
>
>
> On 10/4/22 08:13, Aldy Hernandez via Gcc-patches wrote:
> > On Tue, Oct 4, 2022, 13:28 Aldy Hernandez wrote:
> >
> >> On Tue, Oct 4, 2022 at 9:55 AM Richard Biener
> >> wrote:
> >>>
On Tue, Oct 4, 2022, 13:28 Aldy Hernandez wrote:
> On Tue, Oct 4, 2022 at 9:55 AM Richard Biener
> wrote:
> >
> >
> > Am 04.10.2022 um 09:36 schrieb Aldy Hernandez via Gcc-patches <
> gcc-patches@gcc.gnu.org>:
> > >
> > > The reason the no
On Tue, Oct 4, 2022 at 9:55 AM Richard Biener
wrote:
>
>
> Am 04.10.2022 um 09:36 schrieb Aldy Hernandez via Gcc-patches
> :
> >
> > The reason the nonzero mask was kept in a tree was basically inertia,
> > as everything in irange is a tree. However, there's no
The reason the nonzero mask was kept in a tree was basically inertia,
as everything in irange is a tree. However, there's no need to keep
it in a tree, as the conversions to and from wide ints are very
annoying. That, plus special casing NULL masks to be -1 is prone
to error.
I have not only
__builtin_popcount and __builtin_ffs were sharing the same range-ops
entry, but the nonzero mask optimization is not valid for ffs.
Separate them out into two entries.
PR tree-optimization/107130
gcc/ChangeLog:
* gimple-range-op.cc (class cfn_popcount): Call op_cfn_ffs.
There is no need to compare nonzero masks when comparing two VARYING
ranges, as they are always the same when range types are the same.
gcc/ChangeLog:
* value-range.cc (irange::legacy_equal_p): Remove nonozero mask
check when comparing VR_VARYING ranges.
---
gcc/value-range.cc |
Currently if we have a range of [0,0] and we set the nonzero bits to
1, the current code pessimizes the range to [0,1] because it assumes
the range is [1,1] plus the possibility of 0. This fixes the
oversight.
gcc/ChangeLog:
* value-range.cc (irange::set_nonzero_bits): Do not pessimize
Committed as obvious.
gcc/ChangeLog:
* ipa-prop.cc (struct ipa_vr_ggc_hash_traits): Do not compare
incompatible ranges in ipa-prop.
---
gcc/ipa-prop.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index
There is nothing else to compare when the number of sub-ranges is 0.
gcc/ChangeLog:
* value-range.cc (irange::operator==): Early bail on m_num_ranges
equal to 0.
---
gcc/value-range.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
The legacy popcount folding didn't actually fold singleton ranges.
I don't think anyone noticed because there are match.pd patterns that
pick up the slack using the global nonzero bits set by CCP.
It's good form to handle this, even without CCP's help.
Tested on x86-64 Linux.
p.s. This doesn't
When setting the nonzero bits to a mask containing only one bit, set
the range immediately, as it can be devined from the mask. This helps
us keep better track of powers of two.
For example, with this patch a nonzero mask of 0x8000 is set to a
range of [0,0][0x8000,0x8000] with a nonzero mask of
Just the same way as we have real_value setters for franges, we should
have a wide_int version for irange. This matches the irange
constructor for wide_ints, and paves the way for the eventual
conversion of irange to wide ints.
gcc/ChangeLog:
* value-range.h (irange::set): New version
For [0 = x & MASK], we can determine that x is ~MASK. This is
something we're picking up in DOM thanks to maybe_set_nonzero_bits,
but is something we should handle natively.
This is a good example of how much easier to maintain the range-ops
entries are versus the ad-hoc pattern matching stuff
In the conversion of DOM+evrp to DOM+ranger, we missed that evrp was
exporting ranges for unreachable edges for all SSA names for which we
have ranges for. Instead we have only been exporting ranges for the
SSA name in the final conditional to the BB involving the unreachable
edge.
This patch
The frange setter does all its work in trees. This incurs a penalty
for the real_value variants because they must wrap their arguments
into a tree and pass it to the tree setter, which will then do the
opposite. This is leftovers from the irange setter.
Even though the we still need
:
>
> On Thu, Sep 22, 2022 at 6:49 PM Aldy Hernandez wrote:
> >
> > Similarly to how we drop NANs to UNDEFINED when -ffinite-math-only, I
> > think we can drop the numbers outside of the min/max representable
> > numbers to the representable number.
> >
> &
On Fri, Sep 23, 2022 at 8:54 AM Richard Biener
wrote:
>
> On Thu, Sep 22, 2022 at 6:48 PM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > We currently have no way of dumping REAL_VALUE_TYPEs when debugging.
> >
> > Tested on a gdb session examining the real value
On Thu, Sep 22, 2022 at 11:04 PM Jakub Jelinek wrote:
>
> On Thu, Sep 22, 2022 at 06:49:10PM +0200, Aldy Hernandez wrote:
> > It has been suggested that if we start bumping numbers by an ULP when
> > calculating open ranges (for example the numbers less than 3.0
It has been suggested that if we start bumping numbers by an ULP when
calculating open ranges (for example the numbers less than 3.0) that
dumping these will become increasingly harder to read, and instead we
should opt for the hex representation. I still find the floating
point representation
Similarly to how we drop NANs to UNDEFINED when -ffinite-math-only, I
think we can drop the numbers outside of the min/max representable
numbers to the representable number.
This means the endpoings to VR_VARYING for -ffinite-math-only can now
be the min/max representable, instead of -INF and
We currently have no way of dumping REAL_VALUE_TYPEs when debugging.
Tested on a gdb session examining the real value 10.0:
(gdb) p min
$9 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 4,
sig = {0, 0, 11529215046068469760}}
(gdb) p debug (min)
0x0.ap+4
OK for trunk?
On Thu, Sep 22, 2022 at 5:22 PM Jakub Jelinek wrote:
>
> On Thu, Sep 22, 2022 at 05:02:19PM +0200, Aldy Hernandez wrote:
> > It has always irritated me that we don't have TYPE_MIN_VALUE and
> > TYPE_MAX_VALUE for floats (and for pointers for that matter). This
> > means
It has always irritated me that we don't have TYPE_MIN_VALUE and
TYPE_MAX_VALUE for floats (and for pointers for that matter). This
means, we have to recalculate it ad-nauseum in vrp_val_min and
vrp_val_max.
I know we have dconstinf and dconstninf for floats, which we can just
wrap around a
Richard, this is what you suggested. Thanks.
Explicit NANs in the IL can be treated as undefined for
flag_finite_math_only. This causes all the right things to happen wrt
threading, folding, etc. It also saves us special casing throughout.
It occurs to me that we should do something similar
Since NANs can be inserted by other passes even for -ffinite-math-only,
we can't depend on the flag to determine if a NAN is a possiblity.
Instead, we must explicitly check for them.
In the case of -ffinite-math-only, paths leading up to a NAN are
undefined and can be considered unreachable. I
, Sep 21, 2022 at 9:39 AM Richard Biener
wrote:
>
> On Tue, Sep 20, 2022 at 8:23 PM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Undefined ranges have undefined NAN bits. We can't depend on them,
> > as they may contain garbage.
>
> Ick ;) Can you add a c
Undefined ranges have undefined NAN bits. We can't depend on them,
as they may contain garbage. This patch returns false from
maybe_isnan() for undefined ranges (the empty set).
gcc/ChangeLog:
* value-range.h (frange::maybe_isnan): Return false for
undefined ranges.
---
On Tue, Sep 20, 2022 at 5:10 PM Jakub Jelinek wrote:
>
> On Tue, Sep 20, 2022 at 04:58:38PM +0200, Aldy Hernandez wrote:
> > > > > deal with NaNs just fine and is required to correctly capture the
> > > > > sign of
> > > > > 'x'.
On Tue, Sep 20, 2022 at 2:51 PM Michael Matz wrote:
>
> Hello,
>
> On Tue, 20 Sep 2022, Aldy Hernandez wrote:
>
> > > FWIW, in IEEE, 'abs' (like 'copy, 'copysign' and 'negate') are not
> > > arithmetic, they are quiet-computational. Hence they don't rise
&
PR tree-optimization/106970
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr106970.c: New test.
---
gcc/testsuite/gcc.dg/tree-ssa/pr106970.c | 9 +
1 file changed, 9 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr106970.c
diff --git
On Mon, Sep 19, 2022 at 3:42 PM Richard Biener
wrote:
>
> On Mon, Sep 19, 2022 at 2:52 PM Aldy Hernandez wrote:
> >
> > On Mon, Sep 19, 2022 at 10:14 AM Richard Biener
> > wrote:
> > >
> > > On Mon, Sep 19, 2022 at 9:59 AM Aldy Hernandez wrote
On Mon, Sep 19, 2022 at 4:04 PM Michael Matz wrote:
>
> Hello,
>
> On Mon, 19 Sep 2022, Richard Biener via Gcc-patches wrote:
>
> > > but I guess it's good we do the right thing for correctness sake, and
> > > if it ever gets used by someone else.
> > >
> > > >
> > > > That said,
On Mon, Sep 19, 2022 at 3:45 PM Richard Biener
wrote:
>
> On Mon, Sep 19, 2022 at 3:04 PM Aldy Hernandez wrote:
> >
> > On Mon, Sep 19, 2022 at 9:37 AM Richard Biener
> > wrote:
> > >
> > > On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patch
On Mon, Sep 19, 2022 at 3:04 PM Aldy Hernandez wrote:
>
> On Mon, Sep 19, 2022 at 9:37 AM Richard Biener
> wrote:
> >
> > On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
> > wrote:
> > >
> > > Jakub has mentioned that for -funsafe-ma
On Mon, Sep 19, 2022 at 9:37 AM Richard Biener
wrote:
>
> On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Jakub has mentioned that for -funsafe-math-optimizations we may flush
> > denormals to zero, in which case we need to be caref
On Mon, Sep 19, 2022 at 10:14 AM Richard Biener
wrote:
>
> On Mon, Sep 19, 2022 at 9:59 AM Aldy Hernandez wrote:
> >
> > ISTM that a specifically nonnegative range should not contain -NAN,
> > otherwise signbit_p() would return false, because we'd be unsure of the
&g
ISTM that a specifically nonnegative range should not contain -NAN,
otherwise signbit_p() would return false, because we'd be unsure of the
sign.
Do y'all agree?
PR 68097/tree-optimization
gcc/ChangeLog:
* value-range.cc (frange::set_nonnegative): Set +NAN.
Pushed. We can address any further changes as follow-ups.
Thanks.
Aldy
On Fri, Sep 16, 2022 at 3:26 PM Aldy Hernandez wrote:
>
> On Fri, Sep 16, 2022 at 10:33 AM Richard Sandiford
> wrote:
> >
> > Aldy Hernandez via Gcc-patches writes:
> > > On Thu, Sep 15,
Jakub has mentioned that for -funsafe-math-optimizations we may flush
denormals to zero, in which case we need to be careful to extend the
ranges to the appropriate zero. This patch does exactly that. For a
range of [x, -DENORMAL] we flush to [x, -0.0] and for [+DENORMAL, x]
we flush to [+0.0,
Long doubles are tricky when it comes to considering singletons
because small numbers and +-INF can have multiple representations for
the same number. So we need to be very careful not to treat those as
singletons, lest they be incorrectly propagated by VRP. This is
similar to the -0.0 and +0.0
On Fri, Sep 16, 2022 at 10:33 AM Richard Sandiford
wrote:
>
> Aldy Hernandez via Gcc-patches writes:
> > On Thu, Sep 15, 2022 at 9:06 AM Richard Biener
> > wrote:
> >>
> >> On Thu, Sep 15, 2022 at 7:41 AM Aldy Hernandez wrote:
> >> >
> &g
On Thu, Sep 15, 2022 at 9:06 AM Richard Biener
wrote:
>
> On Thu, Sep 15, 2022 at 7:41 AM Aldy Hernandez wrote:
> >
> > Hi Richard. Hi all.
> >
> > The attatched patch rewrites the NAN and sign handling, dropping both
> > tristates in favor of a pair of
Hi Richard. Hi all.
The attatched patch rewrites the NAN and sign handling, dropping both
tristates in favor of a pair of boolean flags for NANs, and nothing at
all for signs. The signs are tracked in the range itself, so now it's
possible to describe things like [-0.0, +0.0] +NAN, [+0, +0],
Following are a series of cleanups to the frange code in preparation
for a much more invasive patch rewriting the NAN and sign tracking
bits. Please be patient, as I'm trying to break everything up into
small chunks instead of dropping a mondo patch removing the NAN and
sign tristate handling.
set_* has a very specific meaning for irange's and friends. Methods
prefixed with set_* are setters clobbering the existing range. As
such, the current set_nan() method is confusing in that it's not
actually setting a range to a NAN, but twiddling the NAN flags for an
existing frange.
This
The build_ helper functions in range-op-float.cc take the
actual value from the operand's endpoint, but this value could be
deduced from the operand itself therefore cleaning up the call site.
This also reduces the potential of mistakenly passing the wrong bound.
No functional changes.
Every time there's equality at play, we must be careful that any
equality with zero matches both -0.0 and +0.0 when honoring signed
zeros.
We were doing this correctly for the == and != op1_range operators
(albeit inefficiently), but aren't doing it at all when building >=
and <=. This fixes the
This patch cleans up the frange::set() code by passing all things NAN
to frange::set_nan().
No functional changes.
Regstrapped on x86-64 Linux, plus I ran selftests for
-ffinite-math-only.
gcc/ChangeLog:
* value-range.cc (frange::set): Use set_nan.
* value-range.h
This assert was put here to make sure that the legacy
get_value_range() wasn't being called on stuff that legacy couldn't
handle (floats, etc), because the result would ultimately be copied
into a value_range_equiv.
In this case, simplify_casted_cond() is calling it on an offset_type
which is
On Mon, Sep 12, 2022 at 10:48 AM Jan-Benedict Glaw wrote:
>
> Hi Aldy!
>
> On Thu, 2022-09-08 12:56:24 +0200, Aldy Hernandez via Gcc-patches
> wrote:
>
> > From 795baa0b044953e9f198f49e379374d633f43b47 Mon Sep 17 00:00:00 2001
> > From: Aldy Hernandez
> >
We should avoid pessimizing the signbit when it's already correct. In
this particular case we were trying to change the signbit to "unknown",
when it was obviously negative.
This test is actually slated for removal with my upcoming revamp of the
signbit and NAN tracking, per the conversations
On Thu, Sep 8, 2022 at 9:27 AM Richard Biener
wrote:
>
>
>
> > Am 08.09.2022 um 08:28 schrieb Aldy Hernandez :
> >
> > This is what I have in mind for the fpclassify-like methods on the
> > current implementation. I'll get to the removal of the tristates a
This is what I have in mind for the fpclassify-like methods on the
current implementation. I'll get to the removal of the tristates after
Cauldron.
As you mentioned, isnormal is kinda tricky, and likely to be confusing
for the user. We can revisit it if it's important.
?? I assume maybe_inf()
PR tree-optimization/106867
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr106867.c: New test.
---
gcc/testsuite/gcc.dg/tree-ssa/pr106867.c | 16
1 file changed, 16 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr106867.c
diff --git
On Tue, Sep 6, 2022 at 2:17 PM Richard Biener
wrote:
>
> On Tue, Sep 6, 2022 at 2:06 PM Jakub Jelinek wrote:
> >
> > On Tue, Sep 06, 2022 at 01:47:43PM +0200, Aldy Hernandez wrote:
> > > Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
> >
On Tue, Sep 6, 2022 at 9:59 AM Jakub Jelinek wrote:
>
> On Tue, Sep 06, 2022 at 09:49:55AM +0200, Aldy Hernandez wrote:
> > On Tue, Sep 6, 2022 at 9:44 AM Jakub Jelinek wrote:
> > >
> > > On Tue, Sep 06, 2022 at 09:40:59AM +0200, Aldy Hernand
On Tue, Sep 6, 2022, 11:09 Richard Biener
wrote:
> On Tue, Sep 6, 2022 at 9:21 AM Aldy Hernandez wrote:
> >
> > On Mon, Sep 5, 2022 at 2:16 PM Richard Biener
> > wrote:
> > >
> > > On Mon, Sep 5, 2022 at 1:45 PM Aldy Hernandez
> wrote:
> > >
On Tue, Sep 6, 2022 at 9:44 AM Jakub Jelinek wrote:
>
> On Tue, Sep 06, 2022 at 09:40:59AM +0200, Aldy Hernandez wrote:
> > if (x <= Inf)
>
> This will be [-Inf, Inf] !NAN on the true side and
> NAN (either sign) on the false side indeed.
>
> > if (x <
On Tue, Sep 6, 2022 at 9:35 AM Jakub Jelinek wrote:
>
> On Tue, Sep 06, 2022 at 09:29:01AM +0200, Aldy Hernandez wrote:
> > The gfortran.dg/minlocval*.f90 tests are generating conditionals past
> > the infinities. For example:
> >
> > if (x <= +Inf)
&g
The gfortran.dg/minlocval*.f90 tests are generating conditionals past
the infinities. For example:
if (x <= +Inf)
foo (x);
else
bar (x);
It seems to me that the only possible value for x on the false side is
either NAN or undefined (for !HONOR_NANS).
Is this
On Mon, Sep 5, 2022 at 2:16 PM Richard Biener
wrote:
>
> On Mon, Sep 5, 2022 at 1:45 PM Aldy Hernandez wrote:
> >
> > On Mon, Sep 5, 2022 at 12:38 PM Richard Biener
> > wrote:
> > >
> > > On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez wrote:
>
I had some queued up work to try harder to keep the sign bit up to
date in the presence of NANs, but after the discussion with Richi
regarding the representation of NAN and signs in the frange, I've
decided to put it aside until after Cauldron, since it'll probably get
rewritten anyhow. So for
Updating a definite NAN to a definitely not NAN was an assertion
failure, but it turns out we can have such a scenario while attempting
to thread an impossible path. This patch updates the range to
undefined.
What happens in the testcase is that we are trying to thread path that
starts like
Final version of the patch. Disable frange for DECIMAL_FLOAT_MODE_P altogether.
Tested on x86-64 Linux with regstrap as well as mpfr tests.
On Mon, Sep 5, 2022 at 3:47 PM Aldy Hernandez wrote:
>
> As Jakub mentioned in the PR, because many numbers have multiple
> possible representa
As Jakub mentioned in the PR, because many numbers have multiple
possible representations, we can't reliably return true here.
I'll commit this if tests pass.
I wonder if its worth even handling decimal floats in frange, since
there's a lot of things we can't represent. I suppose even though we
On Mon, Sep 5, 2022 at 12:38 PM Richard Biener
wrote:
>
> On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez wrote:
> >
> > On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
> > wrote:
> > >
> > > On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez wrote:
>
On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
wrote:
>
> On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez wrote:
> >
> > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
> > wrote:
> > >
> > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez wrote:
>
On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
wrote:
>
> On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez wrote:
> >
> > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek wrote:
> > >
> > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> &g
On Mon, Sep 5, 2022 at 11:14 AM Richard Biener
wrote:
>
> On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek wrote:
> >
> > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > >
On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek wrote:
>
> On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > wrote:
> > >
> > > Intersecting two ranges where one is a NAN is k
After Joseph's comment wrt __builtin_signbit, I have been unable to
convince myself that arbitrarily folding __builtin_signbit () of a
negative number to 1 is correct.
For example, on the true side of x < -5.0 we know the sign bit is set,
but on the false side, we know nothing because X may be a
Intersecting two ranges where one is a NAN is keeping the sign bit of
the NAN range. This is not correct as the sign bits may not match.
I think the only time we're absolutely sure about the intersection of
a NAN and something else, is when both are a NAN with exactly the same
properties (sign
When unioning a known NAN and something else, we're dropping the
properties of the NAN, particularly the sign. This fixes the
oversight.
With this patch, we should be keeping the sign bit up to date, even in
the presence of NANs.
gcc/ChangeLog:
* value-range.cc (frange::union_): Do not
Possible NANs can never be a singleton, so they will never be
propagated. This was the intent, and then the signed zero code crept
in, and was mistakenly checked before the NAN.
PR 106819
gcc/ChangeLog:
* value-range.cc (frange::singleton_p): Move NAN check to the top.
There are 6 idioms of the same check and I'd like to add more.
It seems there are macros as well as functions for things like
REAL_VALUE_ISINF and REAL_VALUE_NEGATIVE. I don't know if there was
historical need for this duplicity, but I think it's cleaner if we
start gravitating towards inline
On Thu, Sep 1, 2022 at 6:41 PM Joseph Myers wrote:
>
> On Thu, 1 Sep 2022, Aldy Hernandez via Gcc-patches wrote:
>
> > Now that we keep track of the signbit, we can use it to fold
> > __builtin_signbit.
> >
> > I am assuming I don't have try too hard to get th
This is kinda obvious.
OK?
gcc/ChangeLog:
* builtins.cc (fold_builtin_inf): Convert use of real_info to dconstinf.
(fold_builtin_fpclassify): Same.
* fold-const-call.cc (fold_const_call_cc): Same.
* match.pd: Same.
* omp-low.cc (omp_reduction_init_op):
gcc/ChangeLog:
* range-op-float.cc (build_le): Convert to dconst*inf.
(build_ge): Same.
* value-range.cc (frange::set_signbit): Same.
(frange::normalize_kind): Same.
(range_tests_floats): Same.
* value-range.h (vrp_val_max): Same.
We're starting to abuse the infinity endpoints in the frange code and
the associated range operators. Building infinities are rather cheap,
and we could even inline them, but I think it's best to just not
recalculate them all the time.
I see about 20 uses of real_inf in the source code, not
As discussed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600656.html
This adds an frange property to keep track of the sign bit. We keep
it updated at all times, but we don't use it make any decisions when
!HONOR_SIGNED_ZEROS.
With this property we can now query the
Now that we keep track of the signbit, we can use it to fold __builtin_signbit.
I am assuming I don't have try too hard to get the actual signbit
number and 1 will do. Especially, since we're inconsistent in trunk whether
we fold the builtin or whether we calculate it at runtime.
abulafia:~$
I'm just shuffling the FP self tests here, with no change to existing
functionality.
If we agree that explicit NANs in the source code with !HONOR_NANS
should behave any differently, I'm happy to address whatever needs
fixing, but for now I'd like to unblock the !HONOR_NANS build systems.
I have
We only stream out the FP properties for global float ranges
(currently only NAN). The following patch adds the endpoints as well.
gcc/ChangeLog:
* value-range-storage.cc (frange_storage_slot::set_frange): Save
endpoints.
(frange_storage_slot::get_frange): Restore
Thanks.
On Wed, Aug 31, 2022 at 2:18 PM Martin Liška wrote:
>
> Fixes:
> gcc/value-range.h:357:16: warning: 'set_nonnegative' overrides
> a member function but is not marked 'override'
> [-Winconsistent-missing-override]
>
> gcc/ChangeLog:
>
> * value-range.h: Add override.
> ---
>
We do have a way of folding the builtin on a forward
analysis, but that's a separate thing.
Thoughts?
Aldy
On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
> > It seems to me we can do this optimization regardl
On Wed, Aug 31, 2022 at 8:22 AM Richard Biener
wrote:
>
> On Tue, Aug 30, 2022 at 5:43 PM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Previously [5,6] U NAN would just drop to VARYING. With this patch,
> > the resulting range becomes [5,6] with the NAN bit set t
Previously [5,6] U NAN would just drop to VARYING. With this patch,
the resulting range becomes [5,6] with the NAN bit set to unknown.
[I still have yet to decide what to do with intersections. ISTM, the
intersection of a known NAN with anything else should be a NAN, but it
could also be
Setting the definite NAN property should also force a [NAN, NAN]
range, otherwise we'd have two ways of representing a NAN: with the
endpoints or with the property. In the ranger world we avoid at all
costs having more than one representation for a range.
In doing this, I removed the
in
reviewing/improving the code for readers. Also, it always helps
regression hunting to have smaller pieces ;-).
Retested on x86-64 Linux.
Pushed.
On Mon, Aug 29, 2022 at 4:42 PM Toon Moene wrote:
>
> On 8/29/22 16:36, Aldy Hernandez wrote:
>
> > On Mon, Aug 29, 2022 at 4:3
501 - 600 of 2587 matches
Mail list logo
