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
On Tue, Aug 30, 2022 at 9:03 AM Richard Biener
wrote:
>
> On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > The upcoming work for frange triggers a regression in
> > gcc.dg/tree-ssa/phi-opt-24.c.
> >
> > For -O2 -fno-signed-ze
The upcoming work for frange triggers a regression in
gcc.dg/tree-ssa/phi-opt-24.c.
For -O2 -fno-signed-zeros, we fail to transform the following into -A:
float f0(float A)
{
// A == 0? A : -Asame as -A
if (A == 0) return A;
return -A;
}
This is because the abs/negative match.pd
On Mon, Aug 29, 2022 at 5:08 PM Jeff Law wrote:
>
>
>
> On 8/29/2022 8:26 AM, Aldy Hernandez wrote:
> > On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >> On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches
On Mon, Aug 29, 2022 at 4:30 PM Toon Moene wrote:
>
> On 8/29/22 16:15, Aldy Hernandez wrote:
>
> > But even with -ffinite-math-only, is there any benefit to propagating
> > a known NAN? For example:
>
> The original intent (in 2002) for the option -ffinite-math-on
On Mon, Aug 29, 2022 at 4:27 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 04:20:16PM +0200, Aldy Hernandez wrote:
> > Sure, I can add the HONOR_NANS, but can we even "see" a NAN in the IL
> > for -ffinite-math-only?
>
> Sure, you can, e.g. __b
On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
> > 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:
>
On Mon, Aug 29, 2022 at 4:17 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 04:08:58PM +0200, Aldy Hernandez wrote:
> > On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> &
On Mon, Aug 29, 2022 at 4:08 PM Toon Moene wrote:
>
> On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote:
>
> > On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
>
> >> For convenience, singleton_p() returns false for a NAN. IMO, it makes
> >>
On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > For convenience, singleton_p() returns false for a NAN. IMO, it makes
> > the implementation cleaner, but I'm not wed to the idea if s
(correctly) a 0.0
into the PHI. Hints? Takers? ;-).
Aldy
On Fri, Aug 26, 2022 at 9:44 PM Andrew Pinski wrote:
>
> On Fri, Aug 26, 2022 at 12:16 PM Aldy Hernandez wrote:
> >
> > On Fri, Aug 26, 2022 at 7:40 PM Andrew Pinski wrote:
> > >
> > > On Fri, Aug 26, 2
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 regardless, but then treat
> > positive and negative zero the same throughout the frange class.
> >
On Fri, Aug 26, 2022 at 6:40 PM Jakub Jelinek wrote:
>
> On Fri, Aug 26, 2022 at 05:46:06PM +0200, Aldy Hernandez wrote:
> > On the true side of x == -0.0, we can't just blindly value propagate
> > the -0.0 into every use of x because x could be +0.0 (or vice versa).
> >
On Fri, Aug 26, 2022 at 7:40 PM Andrew Pinski wrote:
>
> On Fri, Aug 26, 2022 at 8:55 AM Aldy Hernandez wrote:
> >
> > [pinskia: I'm CCing you as the author of the match.pd pattern.]
> >
> > So, as I wrap up the work here (latest patch attached), I see there's
On Fri, Aug 26, 2022, 19:40 Andrew Pinski wrote:
> On Fri, Aug 26, 2022 at 8:55 AM Aldy Hernandez wrote:
> >
> > [pinskia: I'm CCing you as the author of the match.pd pattern.]
> >
> > So, as I wrap up the work here (latest patch attached), I see there's
&g
On Fri, Aug 26, 2022 at 6:34 PM Jeff Law wrote:
>
>
>
> On 8/26/2022 10:24 AM, Aldy Hernandez wrote:
> > On Fri, Aug 26, 2022 at 6:08 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >> On 8/23/2022 4:33 AM, Aldy Hernandez via Gcc
On Fri, Aug 26, 2022 at 6:09 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/26/2022 9:43 AM, Aldy Hernandez via Gcc-patches wrote:
> > Another real.* tweak. This time, adding a real_iszero() entry point
> > to match the real_isnegzero. I could combine this patch with t
On Fri, Aug 26, 2022 at 6:08 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/23/2022 4:33 AM, Aldy Hernandez via Gcc-patches wrote:
> > For the frange implementation with endpoints I'm about to contribute,
> > we need to set REAL_VALUE_TYPEs with negative infinity. Th
that can be done by improving the match.pd pattern,
or should be done elsewhere?
Thanks.
Aldy
From a1f64017defaf6d5841b54e8bc867d63738a9f5c Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Tue, 23 Aug 2022 13:36:33 +0200
Subject: [PATCH] Add support for floating point endpoints to frange.
The curren
frange is using some of the default vrange setters, some of which are
leaving the range in an undefined state. We hadn't noticed this
because neither frange nor unsupported_range, both which use some of
the default implementation, weren't being used much.
We can never go wrong with setting
On the true side of x == -0.0, we can't just blindly value propagate
the -0.0 into every use of x because x could be +0.0 (or vice versa).
With this change, we only allow the transformation if
!HONOR_SIGNED_ZEROS or if the range is known not to contain 0.
Will commit after tests complete.
think we could inline a bunch of these functions in
the header file.
On Tue, Aug 23, 2022 at 12:33 PM Aldy Hernandez wrote:
>
> For the frange implementation with endpoints I'm about to contribute,
> we need to set REAL_VALUE_TYPEs with negative infinity. The support
> is already ther
On Tue, Aug 23, 2022 at 2:16 PM Richard Biener wrote:
>
> The following reverts a hunk from r8-5789-g11ef0b22d68cd1 that
> made compute_control_dep_chain start from function entry rather
> than the immediate dominator of the source block of the edge with
> the undefined value on the PHI node.
The current implementation of frange is just a type with some bits to
represent NAN and INF. We can do better and represent endpoints to
ultimately solve longstanding PRs such as PR24021. This patch adds
these endpoints. In follow-up patches I will add support for
relational operators using
For the frange implementation with endpoints I'm about to contribute,
we need to set REAL_VALUE_TYPEs with negative infinity. The support
is already there in real.cc, but it is awkward to get at. One could
call real_inf() and then negate the value, but I've added the ability
to pass the sign
Like the integer version, when op1 == op2 is known to be true the
ranges are also equal.
gcc/ChangeLog:
* range-op-float.cc (foperator_equal::op1_range): Set range to
range of op2.
---
gcc/range-op-float.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
It looks like we're missing a newline for cases where we don't print
anything.
OK?
gcc/ChangeLog:
* tree-ssa-threadbackward.cc (possibly_profitable_path_p): Always
add newline.
(profitable_path_p): Same.
---
gcc/tree-ssa-threadbackward.cc | 10 +-
1 file
The path_range_query constructor that takes an edge is really a
convenience function for the loop-ch pass. It feels wrong to pollute
the API with such a specialized function that could be done with
a small inline function closer to its user.
As an added benefit, we remove one use of reset_path.
On Thu, Aug 18, 2022, 11:34 Richard Biener wrote:
>
> On Thu, Aug 18, 2022 at 9:58 AM Aldy Hernandez wrote:
> >
> > FWIW, here is a rebased version with the latest trunk.
> >
> > There are no regressions, or differences in threading counts, and the
> &
FWIW, here is a rebased version with the latest trunk.
There are no regressions, or differences in threading counts, and the
performance change is negligible.
Aldy
On Wed, Aug 17, 2022 at 1:59 PM Aldy Hernandez wrote:
>
> These are a bunch of cleanups inspired by Richi's suggestion of
Thanks.
Pushed.
On Wed, Aug 17, 2022 at 3:18 AM Andrew MacLeod wrote:
>
>
> On 8/16/22 21:16, Andrew MacLeod wrote:
> >
> > On 8/16/22 04:21, Aldy Hernandez wrote:
> >> On Thu, Aug 11, 2022 at 1:42 PM Richard Biener
> >> wrote:
> >>
> >>
On Tue, Aug 16, 2022 at 4:12 PM Richard Biener
wrote:
>
> On Tue, Aug 16, 2022 at 3:59 PM Aldy Hernandez wrote:
> >
> > [Richi, I'm trying to make things more obvious for others working for the
> > cose base. What do you think?]
> >
> > This makes a few thi
When we cross a backedge in the path solver, we reset the path
relations and nuke the root oracle. However, we forget to reset it
for the next path. This is causing us to miss threads because
subsequent paths will have no root oracle to use.
With this patch we get 201 more threads in the
These are a bunch of cleanups inspired by Richi's suggestion of making
path_range_query standalone, instead of having to call
compute_ranges() for each path.
I've made the ranger need explicit, and moved the responsibility for
its creation to the caller.
I've also investigated and documented why
On Wed, Aug 17, 2022 at 10:59 AM Richard Biener wrote:
>
> On Wed, 17 Aug 2022, Aldy Hernandez wrote:
>
> > On Wed, Aug 17, 2022 at 10:38 AM Richard Biener wrote:
> > >
> > > On Wed, 17 Aug 2022, Aldy Hernandez wrote:
> > >
> > > > On Wed,
On Wed, Aug 17, 2022 at 10:38 AM Richard Biener wrote:
>
> On Wed, 17 Aug 2022, Aldy Hernandez wrote:
>
> > On Wed, Aug 17, 2022 at 9:54 AM Richard Biener wrote:
> > >
> > > On Wed, 17 Aug 2022, Aldy Hernandez wrote:
> > >
> > > > I just
On Wed, Aug 17, 2022 at 9:54 AM Richard Biener wrote:
>
> On Wed, 17 Aug 2022, Aldy Hernandez wrote:
>
> > I just have a few high level comments.
> >
> > On Tue, Aug 16, 2022 at 4:05 PM Richard Biener wrote:
> > >
> > > The following refacto
I just have a few high level comments.
On Tue, Aug 16, 2022 at 4:05 PM Richard Biener wrote:
>
> The following refactors profitable_path_p in the backward threader,
> splitting out parts that can be computed once the exit block is known,
> parts that contiguously update and that can be checked
[Richi, I'm trying to make things more obvious for others working for the
cose base. What do you think?]
This makes a few things explicit to avoid misuse. First, we add a
flag to differentiate between a path whose depdenency ranges are being
computed, and a path that is finalized and no further
On Tue, Aug 16, 2022 at 3:48 PM Andrew MacLeod wrote:
>
>
> On 8/16/22 06:25, Aldy Hernandez wrote:
> > On Mon, Aug 15, 2022 at 11:53 AM Richard Biener wrote:
> >> The remaining issue I have with the path_range_query is that
> >> we re-use the s
On Tue, Aug 16, 2022, 14:26 Richard Biener wrote:
> On Tue, 16 Aug 2022, Aldy Hernandez wrote:
>
> > On Tue, Aug 16, 2022 at 1:38 PM Richard Biener
> wrote:
> > >
> > > On Tue, 16 Aug 2022, Aldy Hernandez wrote:
> > >
> > > > On
On Tue, Aug 16, 2022 at 1:38 PM Richard Biener wrote:
>
> On Tue, 16 Aug 2022, Aldy Hernandez wrote:
>
> > On Mon, Aug 15, 2022 at 11:53 AM Richard Biener wrote:
> > >
> > > The remaining issue I have with the path_range_query is that
> > > we re-
On Tue, Aug 16, 2022 at 1:32 PM Richard Biener wrote:
>
> On Tue, 16 Aug 2022, Aldy Hernandez wrote:
>
> > On Tue, Aug 16, 2022 at 11:18 AM Richard Biener wrote:
> > >
> > > On Mon, 15 Aug 2022, Aldy Hernandez wrote:
> > >
> > > > On Mon,
On Mon, Aug 15, 2022 at 11:53 AM Richard Biener wrote:
>
> The remaining issue I have with the path_range_query is that
> we re-use the same instance in the back threader but the
> class doesn't provide any way to "restart", aka give m_path
> a lifetime. The "start a new path" API seems to
On Tue, Aug 16, 2022 at 11:18 AM Richard Biener wrote:
>
> On Mon, 15 Aug 2022, Aldy Hernandez wrote:
>
> > On Mon, Aug 15, 2022 at 9:24 PM Andrew MacLeod wrote:
> > >
> > > heh. or just
> > >
> > >
> > > + int_range&l
On Tue, Aug 16, 2022 at 11:08 AM Aldy Hernandez wrote:
>
> On Tue, Aug 16, 2022 at 10:32 AM Richard Biener wrote:
> >
> > On Tue, 16 Aug 2022, Aldy Hernandez wrote:
> >
> > > On Thu, Aug 11, 2022 at 1:42 PM Richard Biener wrote:
> > >
>
Thanks.
On Tue, Aug 16, 2022 at 11:07 AM Martin Liška wrote:
>
> Pushing as it follows the same pattern as:
>
> virtual void set (tree, tree, value_range_kind = VR_RANGE) override;
>
> Martin
>
> Address:
>
> gcc/value-range-equiv.h:57:8: warning: 'set_undefined' overrides a member
> function
On Tue, Aug 16, 2022 at 10:32 AM Richard Biener wrote:
>
> On Tue, 16 Aug 2022, Aldy Hernandez wrote:
>
> > On Thu, Aug 11, 2022 at 1:42 PM Richard Biener wrote:
> >
> > > @@ -599,6 +592,30 @@ path_range_query::compute_imports (bi
On Mon, Aug 15, 2022 at 11:53 AM Richard Biener wrote:
>
> On Thu, 11 Aug 2022, Aldy Hernandez wrote:
>
> > On Thu, Aug 11, 2022 at 3:59 PM Andrew MacLeod wrote:
> > >
> > >
> > > On 8/11/22 07:42, Richard Biener wrote:
> > > > This avoid
On Thu, Aug 11, 2022 at 1:42 PM Richard Biener wrote:
> @@ -599,6 +592,30 @@ path_range_query::compute_imports (bitmap imports, const
> vec )
> worklist.safe_push (arg);
> }
> }
> + else if (gassign *ass = dyn_cast (def_stmt))
> + {
> +
On Mon, Aug 15, 2022 at 9:24 PM Andrew MacLeod wrote:
>
> heh. or just
>
>
> + int_range<2> r;
> + if (!fold_range (r, const_cast (cond_stmt))
> + || !r.singleton_p ())
>
>
> if you do not provide a range_query to any of the fold_using_range code,
> it defaults to:
>
>
On Mon, Aug 15, 2022 at 11:39 AM Richard Biener wrote:
>
> On Fri, 12 Aug 2022, Aldy Hernandez wrote:
>
> > On Fri, Aug 12, 2022 at 2:01 PM Richard Biener wrote:
> > >
> > > This started with noticing we add ENTRY_BLOCK to our threads
> > > just f
On Fri, Aug 12, 2022 at 2:01 PM Richard Biener wrote:
>
> This started with noticing we add ENTRY_BLOCK to our threads
> just for the sake of simplifying the conditional at the end of
> the first block in a function. That's not really threading
> anything but it ends up duplicating the entry
On Fri, Aug 12, 2022 at 1:36 PM Richard Biener wrote:
>
> On Fri, 12 Aug 2022, Aldy Hernandez wrote:
>
> > On Fri, Aug 12, 2022 at 12:59 PM Richard Biener wrote:
> > >
> > > With the last re-org I failed to make sure to not add SSA names
> > > no
In that case Richi, go right ahead with your original patch. I for one am
happy we can use range_on_entry, which always seemed cleaner.
Aldy
On Fri, Aug 12, 2022, 16:07 Andrew MacLeod wrote:
>
> On 8/12/22 09:38, Andrew MacLeod wrote:
> >
> > On 8/12/22 07:31, Aldy Hernandez
On Fri, Aug 12, 2022 at 12:59 PM Richard Biener wrote:
>
> With the last re-org I failed to make sure to not add SSA names
> nor supported by ranger into m_imports which then triggers an
> ICE in range_on_path_entry because range_of_expr returns false. I've
> noticed that range_on_path_entry
On Thu, Aug 11, 2022 at 3:59 PM Andrew MacLeod wrote:
>
>
> On 8/11/22 07:42, Richard Biener wrote:
> > This avoids going BBs outside of the path when adding def chains
> > to the set of imports. It also syncs the code with
> > range_def_chain::get_def_chain to not miss out on some imports
> >
OK
On Thu, Aug 11, 2022, 13:42 Richard Biener wrote:
> This avoids going BBs outside of the path when adding def chains
> to the set of imports. It also syncs the code with
> range_def_chain::get_def_chain to not miss out on some imports
> this function would identify.
>
> Bootstrap / regtest
to be making good progress.
Aldy
On Wed, Aug 10, 2022 at 6:10 PM Aldy Hernandez wrote:
>
> Looks good to me.
>
> Thanks.
> Aldy
>
> On Wed, Aug 10, 2022 at 3:01 PM Richard Biener wrote:
> >
> > The following fixes the use of compute_imports from the backwards
>
Looks good to me.
Thanks.
Aldy
On Wed, Aug 10, 2022 at 3:01 PM Richard Biener wrote:
>
> The following fixes the use of compute_imports from the backwards
> threader which ends up accessing stale m_path from a previous
> threading attempt. The fix is to pass in the path explicitely
> (and not
On Wed, Aug 10, 2022 at 12:46 PM Richard Biener wrote:
>
> On Wed, 10 Aug 2022, Richard Biener wrote:
>
> > On Tue, 9 Aug 2022, Andrew MacLeod wrote:
> >
> > >
> > > On 8/9/22 09:01, Richard Biener wrote:
> > > > This revisits how we compute imports later used for the ranger path
> > > > query
I'm still on vacation, but I figured I'd mention a few things to
either unblock you, or move the conversation along.
On Wed, Aug 10, 2022 at 8:45 AM Richard Biener wrote:
>
> On Tue, 9 Aug 2022, Andrew MacLeod wrote:
>
> >
> > On 8/9/22 09:01, Richard Biener wrote:
> > > This revisits how we
An unsupported_range temporary is instantiated in every Value_Range
for completeness sake and should be mostly a NOP. However, it's
showing up in the callgrind stats, because it's not inline. This
fixes the oversight.
PR tree-optimization/106514
gcc/ChangeLog:
* value-range.cc
On Thu, Aug 4, 2022 at 9:15 AM Richard Biener wrote:
>
> On Thu, 4 Aug 2022, Aldy Hernandez wrote:
>
> > On Wed, Aug 3, 2022 at 11:53 AM Richard Biener wrote:
> > >
> > > I've tried to understand how the greedy search works seeing the
> > > bitmap da
On Wed, Aug 3, 2022 at 11:53 AM Richard Biener wrote:
>
> I've tried to understand how the greedy search works seeing the
> bitmap dances and the split into resolve_phi. I've summarized
> the intent of the algorithm as
>
> // For further greedy searching we want to remove interesting
>
I missed the -details dump flag, plus I wasn't checking the actual folding.
As a bonus I had flipped the dump file name and the count, so the test
was coming out as unresolved, which I missed because I was only checking
for failures and passes.
Whooops.
gcc/testsuite/ChangeLog:
*
Feel free to blame me for everything except the profitability code and the
generic block copier. That stuff was all there before and I mostly avoided
it.
:-)
Thanks for the work in this space.
Aldy
On Tue, Aug 2, 2022, 15:29 Richard Biener wrote:
> On Tue, 2 Aug 2022, Aldy Hernandez wr
changing diapers, but without a laptop.
Feedback still welcome; I'll just address it as a follow-up.
Pushed.
Aldy
On Sun, Jul 31, 2022 at 8:11 PM Aldy Hernandez wrote:
>
> PING
>
> Andrew, anyone, would you mind giving this a once over? I realize
> reviewing ranger'
This patch Allows us to export floating point ranges into the SSA name
(SSA_NAME_RANGE_INFO).
[Richi, in PR24021 you suggested that match.pd could use global float
ranges, because it would generally not invoke ranger. This patch
implements the boiler plate to save the frange globally.]
[Jeff,
Will commit pending a final round of tests.
gcc/ChangeLog:
* value-range.cc (frange::set): Initialize m_props and cleanup.
---
gcc/value-range.cc | 47 +++---
1 file changed, 28 insertions(+), 19 deletions(-)
diff --git a/gcc/value-range.cc
ipa-* still works on legacy value_range's which only support
integrals. This patch limits the query to integrals, as to not get a
floating point range that can't exist in an irange.
Will commit pending a final round of tests.
gcc/ChangeLog:
* ipa-prop.cc
On Tue, Aug 2, 2022 at 2:07 PM Richard Biener
wrote:
>
> On Tue, Aug 2, 2022 at 1:41 PM Aldy Hernandez wrote:
> >
> > On Tue, Aug 2, 2022 at 9:19 AM Richard Biener
> > wrote:
> > >
> > > On Mon, Aug 1, 2022 at 8:17 AM Aldy Hernandez via Gcc-patches
On Tue, Aug 2, 2022 at 1:59 PM Richard Biener wrote:
>
> On Tue, 2 Aug 2022, Aldy Hernandez wrote:
>
> > On Tue, Aug 2, 2022 at 1:45 PM Richard Biener wrote:
> > >
> > > On Tue, 2 Aug 2022, Aldy Hernandez wrote:
> > >
> > > > U
On Tue, Aug 2, 2022 at 1:45 PM Richard Biener wrote:
>
> On Tue, 2 Aug 2022, Aldy Hernandez wrote:
>
> > Unfortunately, this was before my time, so I don't know.
> >
> > That being said, thanks for tackling these issues that my work
> > triggered last r
On Tue, Aug 2, 2022 at 9:19 AM Richard Biener
wrote:
>
> On Mon, Aug 1, 2022 at 8:17 AM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Even though ranger is type agnostic, SCEV seems to only work with
> > integers. This patch removes some FIX
Unfortunately, this was before my time, so I don't know.
That being said, thanks for tackling these issues that my work
triggered last release. Much appreciated.
Aldy
On Tue, Aug 2, 2022 at 10:41 AM Richard Biener wrote:
>
> I am trying to make sense of
Even though ranger is type agnostic, SCEV seems to only work with
integers. This patch removes some FIXME notes making it explicit that
bounds_of_var_in_loop only works with iranges.
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-fold.cc (fold_using_range::range_of_phi): Only
Make all vrange::supports_*_p methods const_tree as they can end up
being called from functions that are const_tree.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.cc (vrange::supports_type_p): Use const_tree.
(irange::supports_type_p): Same.
These are some assorted cleanups to the frange class to make it easier
to drop in an implementation with FP endpoints:
* frange::set() had some asserts limiting the type of arguments
passed. There's no reason why we can't handle all the variants.
Worse comes to worse, we can always return a
in the week to have
enough time to field any possible fallout before I take a few days off
next week.
Updated patch attached.
Thanks.
Aldy
On Mon, Jul 25, 2022 at 8:50 PM Aldy Hernandez wrote:
>
> Without further ado, here is the implementation for floating point
> range operators, plus t
Swt!
Would you like me to XFAIL the test or leave it as a failure?
Thanks.
Aldy
On Fri, Jul 29, 2022 at 1:50 PM Jakub Jelinek wrote:
>
> On Fri, Jul 29, 2022 at 01:40:12PM +0200, Aldy Hernandez wrote:
> > With my upcoming patch enabling floating point VRP,
> > g++.
On Fri, Jul 29, 2022 at 11:02 AM Richard Biener wrote:
>
> The following makes the backward threader reject threads whose entry
> edge is probably never executed according to the profile. That in
> particular, for the testcase, avoids threading the irq == 1 check
> on the path where irq > 31,
Hi.
With my upcoming patch enabling floating point VRP,
g++.dg/opt/pr94589-2.C is failing:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598788.html
The problem is that phiopt no longer sees the following snippet,
because we have folded away the final conditional as true:
bool f5 (double
Technically iranges only exist in constant form, but we allow symbolic
ones before arriving in the ranger, so legacy VRP can work. This fixes the
ICE when attempting to print symbolic iranges in the pretty printer.
For consistency's sake, I have made sure irange::get_nonzero_bits does
not
opine.
Aldy
On Mon, Jul 25, 2022 at 8:50 PM Aldy Hernandez wrote:
>
> Without further ado, here is the implementation for floating point
> range operators, plus the switch to enable all ranger clients to
> handle floats.
>
> These are bare bone implementations good enough for
Without further ado, here is the implementation for floating point
range operators, plus the switch to enable all ranger clients to
handle floats.
These are bare bone implementations good enough for relation operators
to work, while keeping the NAN bits up to date in the frange. There
is also
\
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
new file mode 100644
index 000..8e9d83e3827
--- /dev/null
+++ b/gcc/range-op-float.cc
@@ -0,0 +1,206 @@
+/* Floating point range operators.
+ Copyright (C) 2022 Free Software Foundation, Inc.
+ Contributed by Aldy Hernandez
A cleaner approach to fix this PR has been suggested by Andrew, which
is to just return false on range_on_edge for unsupported range types.
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range.cc (gimple_ranger::range_on_edge): Return false
when the result range type is
This implements a basic frange class to represent floating point
ranges. Although it is meant to be a base for further development, it
is enough to handle relations and propagate NAN and other properties.
For ranger clients to become floating point aware, we still need the
range-op entries,
Here are a few conversions to type agnostic vrange I found while
working on frange.
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-cache.cc (ranger_cache::edge_range): Convert to vrange.
(ranger_cache::range_from_dom): Same.
* tree-ssa-dom.cc
The global get_nonzero_bits was previously returning -1 for
unsupported types. I dropped this in the conversion to global ranges
and it's causing a problem in the frange work, where CCP is asking for
the nonzero bits of non-integral types. CCP may require further
tweaks, but for now, restore the
Similarly to what we did for the relation oracle, but for the path
oracle. This was found while working on frange, where we can test for
x == x while checking for NANness.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-relation.cc (value_relation::set_relation): Remove assert.
The legacy code in vr_values mostly works on integral types (with few
exceptions such as some conversions from float). This patch makes
vr_values::range_of_expr not die when asked for a range of an
unsupported type. It also keeps the min/max simplification code from
being called on non
On Fri, Jul 15, 2022 at 11:40 AM Aldy Hernandez wrote:
>
> This changes the ad-hoc dumping of ranges in the gimple pretty printer
> to use the pp_vrange utility function, which has the benefit of
> handling all range types going forward and unifying the dumping code.
We frequently do operations on the various (upcoming) range types.
The cascading if/switch statements of is_a<> are getting annoying and
repetitive.
The classic visitor pattern provides a clean way to implement classes
handling various range types without the need for endless
conditionals. It
sks (const irange ) const
+{
+ wide_int nz = r.get_nonzero_bits ();
+ if (nz == -1)
+return;
+
+ pp_string (pp, " NONZERO ");
+ char buf[WIDE_INT_PRINT_BUFFER_SIZE];
+ print_hex (nz, buf);
+ pp_string (pp, buf);
+}
diff --git a/gcc/value-range-pretty-print.h b/gcc/value-range-pretty-
This changes the ad-hoc dumping of ranges in the gimple pretty printer
to use the pp_vrange utility function, which has the benefit of
handling all range types going forward and unifying the dumping code.
Instead of:
# RANGE [0, 51] NONZERO 0x3f
# RANGE ~[5, 10]
we would now get:
601 - 700 of 2591 matches
Mail list logo
