In trying to come up with a missing testcase for commit 979e0fbf53cd,
I've realized the patch doesn't catch anything.
A relation of VREL_EQ in foperator_ltgt::fold_range() is either both
arguments the same (x LTGT_EXPR x), which we should never emit, or two
arguments that are actually the same, in
In the conversion of iranges to wide_int (commit cb779afeff204f), I
mistakenly made contains_zero_p() return TRUE for undefined ranges.
This means the rest of the patch was adjusted for this stupidity.
For example, we ended up doing the following, to make up for the fact
that contains_zero_p was b
LTGT_EXPR hasn't been handling relations, especially with NANs as a
possibility. This handles them while documenting how relations work
in a world with NANs.
Basically we need to special case VREL_EQ before calling
frelop_early_resolve. Note that VREL_EQ on entry to a range-op entry
is really VR
[Jakub/Andrew: I've been staring at this for far too long and could
use another pair of eyes.]
This patch implements a new frelop_early_resolve() that handles the
NAN special cases instead of calling into the integer version which
can break for some combinations. Relaxing FP conditional folding i
When one operand is a known NAN, we always return TRUE from
union_nans(), even if no change occurred. This patch fixes the
oversight.
gcc/ChangeLog:
* value-range.cc (frange::union_nans): Return false if nothing
changed.
(range_tests_floats): New test.
---
gcc/value-rang
The mask/value pair we track in the irange is a bit fickle in that it
can sometimes contradict the bitmask inherent in the range. This can
happen when a series of calculations yield a combination such as:
[3, 1000] MASK 0xfffe VALUE 0x0
The mask/value above implies that the lowest bi
On 7/31/23 18:47, Martin Jambor wrote:
Hello,
On Tue, Jul 18 2023, Aldy Hernandez wrote:
On 7/17/23 15:14, Aldy Hernandez wrote:
Instead of reading the known zero bits in IPA, read the value/mask
pair which is available.
There is a slight change of behavior here. I have removed the check
f
On 8/3/23 16:29, Jeff Law wrote:
On 8/3/23 08:23, Jan Hubicka wrote:
Jeff, an help would be appreciated here :)
I will try to debug this. One option would be to disable branch
prediciton on vect_check for time being - it is not inlined anyway
Not a lot of insight. The backwards threader
PING * 2
On Tue, Jul 25, 2023 at 8:32 AM Aldy Hernandez wrote:
>
> Ping
>
> On Mon, Jul 17, 2023, 15:14 Aldy Hernandez wrote:
>>
>> Instead of reading the known zero bits in IPA, read the value/mask
>> pair which is available.
>>
>> There is a slight change of behavior here. I have removed the
Now that we can generically handle bitmasks for unary operators,
there's no need to special case them.
gcc/ChangeLog:
* range-op-mixed.h (class operator_cast): Add update_bitmask.
* range-op.cc (operator_cast::update_bitmask): New.
(operator_cast::fold_range): Call update_
gcc/ChangeLog:
* range-op.cc (class operator_absu): Add update_bitmask.
(operator_absu::update_bitmask): New.
---
gcc/range-op.cc | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index bfab53caea0..5653ca0d186 100644
--- a/gcc/range-op
gcc/ChangeLog:
* range-op-mixed.h (class operator_abs): Add update_bitmask.
* range-op.cc (operator_abs::update_bitmask): New.
---
gcc/range-op-mixed.h | 2 ++
gcc/range-op.cc | 6 ++
2 files changed, 8 insertions(+)
diff --git a/gcc/range-op-mixed.h b/gcc/range-op-mixed
gcc/ChangeLog:
* range-op-mixed.h (class operator_bitwise_not): Add update_bitmask.
* range-op.cc (operator_bitwise_not::update_bitmask): New.
---
gcc/range-op-mixed.h | 2 ++
gcc/range-op.cc | 7 +++
2 files changed, 9 insertions(+)
diff --git a/gcc/range-op-mixed.h b/g
It looks like we missed out on bitmasks for unary operators because we
were using bit_value_binop exclusively. This patch hands off to
bit_value_unop when appropriate, thus allowing us to handle ABS and
BIT_NOT_EXPR, and others. Follow-up patches will add the tweaks for the
range-ops entries them
The frange bits look fine to me, so if you feel confident in the math
logic, go right ahead :).
Thanks.
Aldy
On 7/24/23 18:01, Jakub Jelinek wrote:
Hi!
IEEE754 says that x + (-x) and x - x result in +0 in all rounding modes
but rounding towards negative infinity, in which case the result is -
bit_value_binop initializes VAL regardless of the final mask. It even
has a comment to that effect:
/* Ensure that VAL is initialized (to any value). */
However, bit_value_unop, which in theory shares the same API, does not.
This causes range-ops to choke on uninitialized VALs for some inputs
Committed as obvious.
gcc/ChangeLog:
* tree-ssa-ccp.cc (value_mask_to_min_max): Make static.
(bit_value_mult_const): Same.
(get_individual_bits): Same.
---
gcc/tree-ssa-ccp.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/tree-ssa-ccp.cc b/
Ping
On Mon, Jul 17, 2023, 15:14 Aldy Hernandez wrote:
> Instead of reading the known zero bits in IPA, read the value/mask
> pair which is available.
>
> There is a slight change of behavior here. I have removed the check
> for SSA_NAME, as the ranger can calculate the range and value/mask for
On 7/17/23 15:14, Aldy Hernandez wrote:
Instead of reading the known zero bits in IPA, read the value/mask
pair which is available.
There is a slight change of behavior here. I have removed the check
for SSA_NAME, as the ranger can calculate the range and value/mask for
INTEGER_CST. This sim
Instead of reading the known zero bits in IPA, read the value/mask
pair which is available.
There is a slight change of behavior here. I have removed the check
for SSA_NAME, as the ranger can calculate the range and value/mask for
INTEGER_CST. This simplifies the code a bit, since there's no spe
Currently IPA throws away the known 1 bits because VRP and irange have
traditionally only had a way of tracking known 0s (set_nonzero_bits).
With the ability to keep all the known bits in the irange, we can now
save this between passes.
OK?
gcc/ChangeLog:
* ipa-prop.cc (ipcp_update_bits)
Currently CCP throws away the known 1 bits because VRP and irange have
traditionally only had a way of tracking known 0s (set_nonzero_bits).
With the ability to keep all the known bits in the irange, we can now
save this between passes.
OK?
gcc/ChangeLog:
* tree-ssa-ccp.cc (ccp_finalize)
The bit twiddling in union/intersect for the value/mask pair must be
normalized to have the unknown bits with a value of 0 in order to make
the math simpler. Normalizing at construction slowed VRP by 1.5% so I
opted to normalize before updating the bitmask in range-ops, since it
was the only user.
This patch provides a way to set the value/mask pair of known bits
globally, similarly to how we can use set_nonzero_bits for known 0
bits. This can then be used by CCP and IPA to set value/mask info
instead of throwing away the known 1 bits.
In further clean-ups, I will see if it makes sense to
On 7/14/23 15:37, Richard Biener wrote:
On Fri, 14 Jul 2023, Aldy Hernandez wrote:
I don't know what you're trying to accomplish here, as I haven't been
following the PR, but adding all these helper functions to the ranger header
file seems wrong, especially since there's only one use of the
I don't know what you're trying to accomplish here, as I haven't been
following the PR, but adding all these helper functions to the ranger
header file seems wrong, especially since there's only one use of them.
I see you're tweaking the irange API, adding helper functions to
range-op (which is
On 7/12/23 23:50, Jeff Law wrote:
On 7/12/23 15:15, Aldy Hernandez via Gcc-patches wrote:
This patch teaches popcount about known set bits which are now
available in the irange.
PR tree-optimization/107053
gcc/ChangeLog:
* gimple-range-op.cc (cfn_popcount): Use known set bits
This patch teaches popcount about known set bits which are now
available in the irange.
PR tree-optimization/107053
gcc/ChangeLog:
* gimple-range-op.cc (cfn_popcount): Use known set bits.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr107053.c: New test.
---
gcc/gimple-r
PR tree-optimization/107043
gcc/ChangeLog:
* range-op.cc (operator_bitwise_and::op1_range): Update bitmask.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr107043.c: New test.
---
gcc/range-op.cc | 8
gcc/testsuite/gcc.dg/tree-ssa/pr10704
Throw the switch in range-ops to make full use of the value/mask
information instead of only the nonzero bits. This will cause most of
the operators implemented in range-ops to use the value/mask
information calculated by CCP's bit_value_binop() function which
range-ops uses. This opens up more o
Integer ranges (irange) currently track known 0 bits. We've wanted to
track known 1 bits for some time, and instead of tracking known 0 and
known 1's separately, it has been suggested we track a value/mask pair
similarly to what we do for CCP and RTL. This patch implements such a
thing.
With thi
Per the function comment, the caller to intersect(wide_int, wide_int)
must handle the mask. This means it must also normalize the range if
anything changed.
gcc/ChangeLog:
* value-range.cc (irange::intersect): Leave normalization to
caller.
---
gcc/value-range.cc | 7 +--
1
gcc/ChangeLog:
* value-range.cc (irange::get_bitmask_from_range): Return all the
known bits for a singleton.
(irange::set_range_from_bitmask): Set a range of a singleton when
all bits are known.
---
gcc/value-range.cc | 19 ++-
1 file changed, 18 in
There's a few spots where a range is being altered in-place, but we
fail to call normalize the range. This patch makes sure we always
call normalize_kind(), and that normalize_kind in turn, calls
verify_range to make sure verything is canonical.
gcc/ChangeLog:
* value-range.cc (frange::s
gcc/ChangeLog:
* tree-vrp.cc (maybe_set_nonzero_bits): Move from here...
* tree-ssa-dom.cc (maybe_set_nonzero_bits): ...to here.
* tree-vrp.h (maybe_set_nonzero_bits): Remove.
---
gcc/tree-ssa-dom.cc | 65 +
gcc/tree-vrp.cc |
ng*2
> >
> > On Wed, Jun 14, 2023, 14:11 Aldy Hernandez wrote:
> >>
> >> PING
> >>
> >> On Sat, Jun 10, 2023 at 10:30 PM Aldy Hernandez wrote:
> >> >
> >> >
> >> >
> >> > On 5/29/23 16:51, Martin Jam
5/29/23 16:51, Martin Jambor wrote:
>> > > Hi,
>> > >
>> > > On Mon, May 22 2023, Aldy Hernandez via Gcc-patches wrote:
>> > >> Implement hashing for ipa_vr. When all is said and done, all these
>> > >> patches incurr a 7.64% slowdo
Ping*2
On Wed, Jun 14, 2023, 14:11 Aldy Hernandez wrote:
> PING
>
> On Sat, Jun 10, 2023 at 10:30 PM Aldy Hernandez wrote:
> >
> >
> >
> > On 5/29/23 16:51, Martin Jambor wrote:
> > > Hi,
> > >
> > > On Mon, May 22 2023, Aldy Hernande
Ping*2
On Wed, Jun 14, 2023, 14:09 Aldy Hernandez wrote:
> PING
>
> On Mon, May 22, 2023 at 8:56 PM Aldy Hernandez wrote:
> >
> > This patch converts the ipa_jump_func code to use the type agnostic
> > ipa_vr suitable for GC instead of value_range which is integer specific.
> >
> > I've disable
Ping*2
On Wed, Jun 14, 2023, 14:10 Aldy Hernandez wrote:
> PING
>
> On Mon, May 22, 2023 at 8:56 PM Aldy Hernandez wrote:
> >
> > Minor cleanups to get rid of value_range in IPA. There's only one left,
> > but it's in the switch code which is integer specific.
> >
> > OK?
> >
> > gcc/ChangeLog
PING
On Sat, Jun 10, 2023 at 10:30 PM Aldy Hernandez wrote:
>
>
>
> On 5/29/23 16:51, Martin Jambor wrote:
> > Hi,
> >
> > On Mon, May 22 2023, Aldy Hernandez via Gcc-patches wrote:
> >> Implement hashing for ipa_vr. When all is said and done, all these
&
PING
On Mon, May 22, 2023 at 8:56 PM Aldy Hernandez wrote:
>
> Minor cleanups to get rid of value_range in IPA. There's only one left,
> but it's in the switch code which is integer specific.
>
> OK?
>
> gcc/ChangeLog:
>
> * ipa-cp.cc (decide_whether_version_node): Adjust comment.
>
PING
On Mon, May 22, 2023 at 8:56 PM Aldy Hernandez wrote:
>
> This patch converts the ipa_jump_func code to use the type agnostic
> ipa_vr suitable for GC instead of value_range which is integer specific.
>
> I've disabled the range cacheing to simplify the patch for review, but
> it is handled
On 5/29/23 16:51, Martin Jambor wrote:
Hi,
On Mon, May 22 2023, Aldy Hernandez via Gcc-patches wrote:
Implement hashing for ipa_vr. When all is said and done, all these
patches incurr a 7.64% slowdown for ipa-cp, with is entirely covered by
the similar 7% increase in this area last week
On 6/10/23 10:49, Martin Jambor wrote:
Hi,
thanks for dealing with my requests.
On Wed, Jun 07 2023, Aldy Hernandez wrote:
On 5/26/23 18:17, Martin Jambor wrote:
Hello,
On Mon, May 22 2023, Aldy Hernandez wrote:
I've adjusted the patch with some minor cleanups that came up when I
impleme
On 6/8/23 20:57, Andrew MacLeod wrote:
Range_operator had a tree code added last release to facilitate bitmask
operations. This was intended to be a temporary change until we could
figure out something more strategic going forward.
This patch removes the tree_code and replaces it with a vi
On 5/26/23 18:17, Martin Jambor wrote:
Hello,
On Mon, May 22 2023, Aldy Hernandez wrote:
I've adjusted the patch with some minor cleanups that came up when I
implemented the rest of the IPA revamp.
Rested. OK?
On Wed, May 17, 2023 at 4:31 PM Aldy Hernandez wrote:
This converts the latti
On 5/29/23 16:51, Martin Jambor wrote:
Hi,
On Mon, May 22 2023, Aldy Hernandez via Gcc-patches wrote:
Implement hashing for ipa_vr. When all is said and done, all these
patches incurr a 7.64% slowdown for ipa-cp, with is entirely covered by
the similar 7% increase in this area last week
My apologies for the delay. I was on vacation.
On 5/26/23 18:17, Martin Jambor wrote:
Hello,
On Mon, May 22 2023, Aldy Hernandez wrote:
I've adjusted the patch with some minor cleanups that came up when I
implemented the rest of the IPA revamp.
Rested. OK?
On Wed, May 17, 2023 at 4:31 PM A
Some minor nits.
+// There can be only one running at a time.
+static phi_analyzer *phi_analysis_object = NULL;
Shouldn't this be phi_analyzer_object to be more consistent? Similarly
throughout.
+// Create a new phi_group with members BM, initialvalue INIT_VAL, modifier
+// statement MOD,
NANs don't have bounds, so there's no need to stream them out.
gcc/ChangeLog:
* data-streamer-in.cc (streamer_read_value_range): Handle NANs.
* data-streamer-out.cc (streamer_write_vrange): Same.
* value-range.h (class vrange): Make streamer_write_vrange a friend.
---
gcc
frange::set() is confusing in that we can set a NAN by specifying a
bound of +-NAN, even though we tecnically disallow NANs in the setter
because the kind can never be VR_NAN. This is a wart for
get_tree_range(), which builds a range out of a tree from the source,
to work correctly. It's ugly, an
We're ICEing when trying to hash a known NAN. This is unnoticeable
because the only user would be IPA, and even so, it currently doesn't
handle floats. However, handling floats is a flip of a switch, so
it's best to handle them already.
gcc/ChangeLog:
* value-range.cc (add_vrange): Hand
Generalize frange::set_nan() to take a nan_state and make current
set_nan() methods syntactic sugar.
This is in preparation for better streaming of NANs for LTO/IPA.
gcc/ChangeLog:
* value-range.h (frange::set_nan): New.
---
gcc/value-range.h | 32 +---
1 fil
gcc/ChangeLog:
* value-range.h (vrange::kind): Remove.
---
gcc/value-range.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 936eb175062..b8cc2a0e76a 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -100,9 +100,6 @@ public:
boo
BTW, we should probably backport this to god knows how many branches.
Aldy
On Tue, May 23, 2023 at 2:58 PM Aldy Hernandez wrote:
>
> [Andrew, do you remotely remember what if anything this did? It came
> from a wholesale merge from our long forgotten branch, so there's no
> history on the speci
[Andrew, do you remotely remember what if anything this did? It came
from a wholesale merge from our long forgotten branch, so there's no
history on the specifics of it. Not important, I'm just curious. It
was probably me high on something.]
This patch removes a buggy special case in irange::in
gcc/ChangeLog:
PR tree-optimization/109920
* value-range.h (RESIZABLE>::~int_range): Use delete[].
---
gcc/value-range.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 171e6426c6e..936eb175062 100644
--- a/gcc/value-
Minor cleanups to get rid of value_range in IPA. There's only one left,
but it's in the switch code which is integer specific.
OK?
gcc/ChangeLog:
* ipa-cp.cc (decide_whether_version_node): Adjust comment.
* ipa-fnsummary.cc (evaluate_conditions_for_known_args): Adjust
fo
Implement hashing for ipa_vr. When all is said and done, all these
patches incurr a 7.64% slowdown for ipa-cp, with is entirely covered by
the similar 7% increase in this area last week. So we get type agnostic
ranges with "infinite" range precision close to free.
There is no change in overall c
This patch converts the ipa_jump_func code to use the type agnostic
ipa_vr suitable for GC instead of value_range which is integer specific.
I've disabled the range cacheing to simplify the patch for review, but
it is handled in the next patch in the series.
OK?
gcc/ChangeLog:
* ipa-cp.
I've adjusted the patch with some minor cleanups that came up when I
implemented the rest of the IPA revamp.
Rested. OK?
On Wed, May 17, 2023 at 4:31 PM Aldy Hernandez wrote:
>
> This converts the lattice to store ranges in Value_Range instead of
> value_range (*) to make it type agnostic, and
I've adjusted the patch with some minor cleanups that came up when I
implemented the rest of the IPA revamp.
Retested. OK?
On Wed, May 17, 2023 at 4:16 PM Aldy Hernandez wrote:
>
> This patch encapsulates the ipa_vr internals into an API. It also
> makes it type agnostic, in preparation for u
This adds some missing accessors to the type agnostic Value_Range
class. They'll be used in the upcoming IPA work.
gcc/ChangeLog:
* value-range.h (class Value_Range): Implement set_zero,
set_nonzero, and nonzero_p.
---
gcc/value-range.h | 3 +++
1 file changed, 3 insertions(+)
On 5/17/23 16:30, Aldy Hernandez wrote:
This converts the lattice to store ranges in Value_Range instead of
value_range (*) to make it type agnostic, and adjust all users
accordingly.
I think it is a good example on converting from static ranges to more
general, type agnostic ones.
I've been
This converts the lattice to store ranges in Value_Range instead of
value_range (*) to make it type agnostic, and adjust all users
accordingly.
I think it is a good example on converting from static ranges to more
general, type agnostic ones.
I've been careful to make sure Value_Range never ends
This patch encapsulates the ipa_vr internals into an API. It also
makes it type agnostic, in preparation for upcoming changes to IPA.
Interestingly, there's a 0.44% improvement to IPA-cp, which I'm sure
we'll soak up with future changes in this area :).
BTW, there's a note here:
+ // vrange_sto
gcc/ChangeLog:
* value-range.h (Value_Range::operator=): New.
---
gcc/value-range.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index ab982d18402..af81d6080da 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@
The unsupported_range class is provided for completness sake. It is a
way to set VARYING/UNDEFINED ranges for unsupported ranges (currently
anything not float, integer, or pointer). You can't do anything with
them, except set_varying, and set_undefined. We will trap on any
other operation.
This
I'm pushing this in preparation for further changes in this area later today.
Aldy
On Thu, Apr 27, 2023 at 1:36 PM Aldy Hernandez wrote:
>
> Thanks. I will put it aside until I start posting the IPA patches.
>
> Aldy
>
> On Thu, Apr 27, 2023, 13:02 Richard Biener wrote:
>>
>> On Tue, Apr 18, 20
On 5/15/23 20:14, Aldy Hernandez wrote:
On 5/15/23 17:07, Aldy Hernandez wrote:
On 5/15/23 12:42, Jakub Jelinek wrote:
On Mon, May 15, 2023 at 12:35:23PM +0200, Aldy Hernandez wrote:
gcc/ChangeLog:
PR tree-optimization/109695
* value-range.cc (irange::operator=): Resize range.
On 5/15/23 17:07, Aldy Hernandez wrote:
On 5/15/23 12:42, Jakub Jelinek wrote:
On Mon, May 15, 2023 at 12:35:23PM +0200, Aldy Hernandez wrote:
gcc/ChangeLog:
PR tree-optimization/109695
* value-range.cc (irange::operator=): Resize range.
(irange::union_): Same.
(irange::inter
On 5/5/23 17:10, Martin Jambor wrote:
Hello,
On Wed, Apr 26 2023, Aldy Hernandez via Gcc-patches wrote:
gcc/ChangeLog:
* ipa-cp.cc (ipa_vr_operation_and_type_effects): Convert to ranger API.
(ipa_value_range_from_jfunc): Same.
(propagate_vr_across_jump_function
On Mon, May 15, 2023 at 5:03 PM Aldy Hernandez wrote:
>
>
>
> On 5/15/23 13:08, Richard Biener wrote:
> > On Mon, May 15, 2023 at 12:35 PM Aldy Hernandez wrote:
> >>
> >>
> >> We can now have int_range for automatically
> >> resizable ranges. int_range_max is now int_range<3, true>
> >> for a 6
On 5/15/23 12:42, Jakub Jelinek wrote:
On Mon, May 15, 2023 at 12:35:23PM +0200, Aldy Hernandez wrote:
gcc/ChangeLog:
PR tree-optimization/109695
* value-range.cc (irange::operator=): Resize range.
(irange::union_): Same.
(irange::intersect): Same.
(ir
On 5/15/23 13:08, Richard Biener wrote:
On Mon, May 15, 2023 at 12:35 PM Aldy Hernandez wrote:
We can now have int_range for automatically
resizable ranges. int_range_max is now int_range<3, true>
for a 69X reduction in size from current trunk, and 6.9X reduction from
GCC12. This incurs a
On 5/15/23 16:24, Bernhard Reutner-Fischer wrote:
On Mon, 15 May 2023 12:35:23 +0200
Aldy Hernandez via Gcc-patches wrote:
+// For resizable ranges, resize the range up to HARD_MAX_RANGES if the
+// NEEDED pairs is greater than the current capacity of the range.
+
+inline void
+irange
We can now have int_range for automatically
resizable ranges. int_range_max is now int_range<3, true>
for a 69X reduction in size from current trunk, and 6.9X reduction from
GCC12. This incurs a 5% performance penalty for VRP that is more than
covered by our > 13% improvements recently.
int_ra
On 5/5/23 17:10, Martin Jambor wrote:
Hello,
On Wed, Apr 26 2023, Aldy Hernandez via Gcc-patches wrote:
gcc/ChangeLog:
* ipa-cp.cc (ipa_vr_operation_and_type_effects): Convert to ranger API.
(ipa_value_range_from_jfunc): Same.
(propagate_vr_across_jump_function
On 5/3/23 13:41, Aldy Hernandez wrote:
[Andrew, since you suggested this, is this what you had in mind?].
Pushed. You can comment when you're back from vacation :).
Aldy
The equal_p method in vrange_storage is only used to compare ranges
that are the same type. No sense passing the type if
On 5/5/23 22:53, Jakub Jelinek wrote:
Hi!
Similarly to the earlier sqrt patch, this patch attempts to improve
sin/cos ranges. As the functions are periodic, for the reverse range
there is not much we can do (but I've discovered I forgot to take
into account the boundary ulps for the discover
On Fri, May 5, 2023 at 11:14 AM Jakub Jelinek wrote:
>
> On Fri, May 05, 2023 at 11:06:31AM +0200, Aldy Hernandez wrote:
> > > +/* Compute FUNC (ARG) where FUNC is a mpfr function. If RES_LOW is
> > > non-NULL,
> > > + set it to low bound of possible range if the function is expected to
> > >
On 5/5/23 10:00, Jakub Jelinek wrote:
Hi!
The previous patch just added basic intrinsic ranges for sqrt
([-0.0, +Inf] +-NAN being the general result range of the function
and [-0.0, +Inf] the general operand range if result isn't NAN etc.),
the following patch intersects those ranges with par
The old legacy code allowed building ranges of unknown types so passes
like IPA could build and propagate VARYING. For now it's easiest to
allow the old behavior, it's not like you can do anything with these
ranges except build them and copy them.
Eventually we should convert all users of set_var
[Andrew, since you suggested this, is this what you had in mind?].
The equal_p method in vrange_storage is only used to compare ranges
that are the same type. No sense passing the type if it can be
determined from the range being compared.
gcc/ChangeLog:
* gimple-range-cache.cc (sbr_spa
Thanks.
On Wed, May 3, 2023, 11:17 Martin Liška wrote:
> Pushed to master as obvious.
>
> Martin
>
> PR tree-optimization/109693
>
> gcc/ChangeLog:
>
> * value-range-storage.cc (vrange_allocator::vrange_allocator):
> Remove unused field.
> * value-range-storage.h:
gcc/ChangeLog:
* value-range.h (class int_range): Remove gt_ggc_mx and gt_pch_nx
friends.
---
gcc/value-range.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 5cff50e6d03..ab8d7d3c5dc 100644
--- a/gcc/value-range.h
+++ b/gcc/val
This converts the irange API to use wide_ints exclusively, along with
its users.
This patch will slow down VRP, as there will be more useless
wide_int to tree conversions. However, this slowdown is only
temporary, as a follow-up patch will convert the internal
representation of iranges to wide_in
irange::set_nonzero is used everywhere and benefits immensely from
inlining.
gcc/ChangeLog:
* value-range.h (irange::set_nonzero): Inline.
---
gcc/value-range.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
Little by little, bounds_of_var_in_loop() has grown into an
unmaintainable mess. This patch rewrites the code to use the relevant
APIs as well as refactor it to make it more readable.
gcc/ChangeLog:
* gimple-range-fold.cc (tree_lower_bound): Delete.
(tree_upper_bound): Delete.
gcc/ChangeLog:
* vr-values.cc (bounds_of_var_in_loop): Convert to irange API.
---
gcc/vr-values.cc | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/vr-values.cc b/gcc/vr-values.cc
index 7f623102ac6..3d28198f9f5 100644
--- a/gcc/vr-values.cc
+++ b/gcc/vr-value
gcc/ChangeLog:
* range-op.cc (update_known_bitmask): Adjust for irange containing
wide_ints internally.
* tree-ssanames.cc (set_nonzero_bits): Same.
* tree-ssanames.h (set_nonzero_bits): Same.
* value-range-storage.cc (irange_storage::set_irange): Same.
gcc/ChangeLog:
* value-range.cc (irange::irange_union): Rename to...
(irange::union_): ...this.
(irange::irange_intersect): Rename to...
(irange::intersect): ...this.
* value-range.h (irange::union_): Delete.
(irange::intersect): Delete.
---
gcc/val
This patch removes all uses of vrp_val_{min,max} in favor for a
irange_val_* which are wide_int based. This will leave only one use
of vrp_val_* which returns trees in range_of_ssa_name_with_loop_info()
because it needs to work with non-integers (floats, etc). In a
follow-up patch, this function
Now that anti-ranges are no more and iranges contain wide_ints instead
of trees, various cleanups are possible. This is one of a handful of
patches improving the performance of irange::set() which is not on a
hot path, but quite sensitive because it is so pervasive.
gcc/ChangeLog:
* gimp
[tl;dr: This is a rewrite of value-range-storage.* such that global
ranges and the internal ranger cache can use the same efficient
storage mechanism. It is optimized such that when wide_ints are
dropped into irange, the copying back and forth from storage will be
very fast, while being able to ho
gcc/ChangeLog:
* vr-values.cc (check_for_binary_op_overflow): Tidy up by using
ranger API.
(compare_ranges): Delete.
(compare_range_with_value): Delete.
(bounds_of_var_in_loop): Tidy up by using ranger API.
(simplify_using_ranges::fold_cond_with_ops)
gcc/ChangeLog:
* tree-ssa-loop-niter.cc (refine_value_range_using_guard): Remove
kind() call.
(determine_value_range): Same.
(record_nonwrapping_iv): Same.
(infer_loop_bounds_from_signedness): Same.
(scev_var_range_cant_overflow): Same.
* tre
gcc/ChangeLog:
* value-range.cc (irange::irange_set_anti_range): Remove uses of
tree_lower_bound and tree_upper_bound.
(irange::verify_range): Same.
(irange::operator==): Same.
(irange::singleton_p): Same.
* value-range.h (irange::tree_lower_bound):
Ok
On Thu, Apr 27, 2023, 15:30 Jakub Jelinek wrote:
> Hi!
>
> The following patch adds sqrt support (but similarly to sincos, only
> dumb basic ranges only).
>
> Ok for trunk if it passes bootstrap/regtest?
>
> Will improve this incrementally and sin/cos as well.
>
> 2023-04-27 Jakub Jelinek
1 - 100 of 1024 matches
Mail list logo
