On 9/29/23 04:37, Jakub Jelinek wrote:
On Thu, Sep 28, 2023 at 11:53:53AM -0400, Aldy Hernandez wrote:
ipa_bits is even worse, because unlike niter analysis, I think it is very
much desirable to support IPA VRP of all supported _BitInt sizes. Shall
we perhaps use trailing_wide_int storage
On Thu, Oct 5, 2023, 8:26 a.m. Jakub Jelinek wrote:
> Hi!
>
> The following patch removes ipa_bits struct pointer/vector from ipa
> jump functions and ipa cp transformations.
>
> The reason is because the struct uses widest_int to represent
> mask/value pair, which in the RFC patches to allow lar
On 07/02/2018 07:08 AM, Christophe Lyon wrote:
On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
While poking around in the backwards threader I noticed that we bail if
we have already seen a starting BB.
/* Do not jump-thread twice from the same block. */
if (bitmap_bit_p
On 07/03/2018 08:16 AM, Martin Liška wrote:
Hi.
It caused UBSAN errors:
$ cat ubsan.i
int a;
void d() { int c, b = 8 - a; }
$ /home/marxin/Programming/gcc2/objdir/./gcc/xgcc
-B/home/marxin/Programming/gcc2/objdir/./gcc/ ubsan.i -c -O2
../../gcc/tree-vrp.c:1715:26: runtime error: load of val
On 07/03/2018 08:16 PM, Jeff Law wrote:
On 07/03/2018 03:31 AM, Aldy Hernandez wrote:
On 07/02/2018 07:08 AM, Christophe Lyon wrote:
On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
While poking around in the backwards threader I noticed that we bail if
we have already seen a starting BB
The reason for this patch are the changes showcased in tree-vrp.c.
Basically I'd like to discourage rolling our own overflow and underflow
calculation when doing wide int arithmetic. We should have a
centralized place for this, that is-- in the wide int code itself ;-).
The only cases I care
On 07/05/2018 05:50 AM, Richard Biener wrote:
On Thu, Jul 5, 2018 at 9:35 AM Aldy Hernandez wrote:
The reason for this patch are the changes showcased in tree-vrp.c.
Basically I'd like to discourage rolling our own overflow and underflow
calculation when doing wide int arithmetic
On 07/05/2018 03:27 PM, Jeff Law wrote:
On 07/04/2018 02:12 AM, Aldy Hernandez wrote:
On 07/03/2018 08:16 PM, Jeff Law wrote:
On 07/03/2018 03:31 AM, Aldy Hernandez wrote:
On 07/02/2018 07:08 AM, Christophe Lyon wrote:
On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
While poking around
On 07/09/2018 04:29 AM, Richard Biener wrote:
On Mon, Jul 9, 2018 at 9:19 AM Aldy Hernandez wrote:
On 07/05/2018 03:27 PM, Jeff Law wrote:
On 07/04/2018 02:12 AM, Aldy Hernandez wrote:
Many tests should turn into gimple IL tests.
Yeah, though for tests like the threading ones
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see that -fno-tree-strlen is never
passed (I think you actually mean -fno-optimize-strlen for that
matter). Also, the builtins.exp harness runs your test f
On 07/09/2018 07:16 AM, Rainer Orth wrote:
and several more. This seems to be the only backend that uses the
additional bool * argument to wi::neg etc.
Fixed as follows, bootstrapped on sparc-sun-solaris2.11.
Thanks. Sorry for the oversight.
Aldy
Howdy!
Attached are more cleanups to VRP getting rid of some repetitive code,
as well as abstracting wide int handling code into their own functions.
There should be no change to existing functionality.
You may notice that I have removed the PLUS/MINUS_EXPR handling in
vrp_int_const_binop, e
On 07/09/2018 03:56 PM, Jeff Law wrote:
On 07/09/2018 01:19 AM, Aldy Hernandez wrote:
I'd like decisions about how to expand branches deferred until rtl
expansion. Kai was poking at this in the past but never really got any
traction.
For the record, the problem in this testcase is
Ho hum, more abstractions.
No change in functionality.
OK for trunk?
gcc/
* vr-values.c (gimple_stmt_nonzero_p): Abstract common code to...
* gimple.c (gimple_call_nonnull_result_p): ...here...
(gimple_call_nonnull_arg): ...and here.
* gimple.h (gimple_call_nonn
I believe I missed this companion patch when I submitted...
Subject: jump threading multiple paths that start from the same BB
The attached patch changes thread_through_all_blocks to allow threads
that start from the same basic block as another thread.
OK for trunk?
gcc/
* tree-ss
d then use a default argument for int_const_binop() to get things going.
Sorry for more changes in flight, but I thought we could benefit from
more cleanups :).
OK for trunk pending tests?
Aldy
On 07/10/2018 04:31 AM, Aldy Hernandez wrote:
Howdy!
Attached are more cleanups to VRP getting r
On 07/11/2018 08:52 AM, Richard Biener wrote:
On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
Hmmm, I think we can do better, and since this hasn't been reviewed yet,
I don't think anyone will mind the adjustment to the patch ;-).
I really hate int_const_binop_SOME_RANDOM_N
On 07/11/2018 01:33 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 07/11/2018 08:52 AM, Richard Biener wrote:
On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
Hmmm, I think we can do better, and since this hasn't been reviewed yet,
I don't think anyone will mind the
On 07/12/2018 04:29 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 07/11/2018 01:33 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 07/11/2018 08:52 AM, Richard Biener wrote:
On Wed, Jul 11, 2018 at 8:48 AM Aldy Hernandez wrote:
Hmmm, I think we can do better, and
On 07/13/2018 03:02 AM, Richard Biener wrote:
On Thu, Jul 12, 2018 at 10:12 AM Aldy Hernandez wrote:
So besides the general discussion about references/pointers for out parameters
let's stay consistet within related APIs. This means wide_int_binop should
have a
wide_int
wide_int_
ux.
OK?
commit eb55ab7557efb23bc6dc34d00eadabf2a73a4995
Author: Aldy Hernandez
Date: Mon Jul 16 14:15:37 2018 +0200
* tree-vrp.c (wide_int_binop_overflow): Rename from
vrp_int_const_binop.
Rewrite to work on trees.
(extract_range_from_multiplicative_op_1): A
Hi again!
Well, since this hasn't been reviewed and I'm about to overhaul the
TYPE_OVERFLOW_WRAPS code anyhow, might as well lump it all in one patch.
On 07/16/2018 09:19 AM, Aldy Hernandez wrote:
Howdy!
I've abstracted out the cross product calculations into its own
fun
On 07/19/2018 04:18 AM, Richard Biener wrote:
On Wed, Jul 18, 2018 at 2:05 PM Aldy Hernandez wrote:
Hi again!
Well, since this hasn't been reviewed and I'm about to overhaul the
TYPE_OVERFLOW_WRAPS code anyhow, might as well lump it all in one patch.
On 07/16/2018 09:1
...well, most of them anyhow...
I got tired of submitting these piecemeal, and it's probably easier to
review them in one go.
There should be no difference in functionality, barring an extra call to
set_and_canonicalize_value_range (instead of set_value_range) due to the
way I've organized m
Now that the floating point version of rv_fold calculates its result
in an frange, we can remove the superfluous LB, UB, and MAYBE_NAN
arguments.
gcc/ChangeLog:
* range-op-float.cc (range_operator::fold_range): Remove
superfluous code.
(range_operator::rv_fold): Remove unn
The floating point version of rv_fold returns its result in 3 pieces:
the lower bound, the upper bound, and a maybe_nan bit. It is cleaner
to return everything in an frange, thus bringing the floating point
version of rv_fold in line with the integer version.
This first patch adds an frange argum
Missed this...
gcc/ChangeLog:
* range-op-float.cc (range_operator::fold_range): Delete unused
variable.
---
gcc/range-op-float.cc | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index ffa3dec133e..75816942f8c 100644
--- a/gcc/range
Hernandez
Date: Mon Nov 4 12:14:56 2019 +0100
Implement debugging functions for assert_info's.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f29939a0dd8..d00348891bd 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2019-11-04 Aldy Hernandez
+
+ * tree-
We are currently ICEing when calling normalize_address on an undefined
range because undefines do not have types.
Committed as obvious.
commit 12cdfbe483c8981ba724582c1faa1432e762b549
Author: Aldy Hernandez
Date: Mon Nov 4 12:16:37 2019 +0100
Handle VR_UNDEFINED in value_range_base
This function is no longer being called. The behavior in it is handled
by the API (value_range_base::singleton_p).
Committed as obvious.
commit 9d22f224ec66efb0abf1394bff7e3d0080498417
Author: Aldy Hernandez
Date: Mon Nov 4 12:46:00 2019 +0100
Remove unused range_int_cst_singleton_p
er can avoid calling these functions.
OK for trunk?
commit 4c4ce7228754d847daa3b99e4ee0d4c466512d1a
Author: Aldy Hernandez
Date: Mon Nov 4 17:55:57 2019 +0100
Remove handle_pointers argument from all the vrp_val*{min,max} functions. Always
assume pointers should be handled.
diff --git a
value_range_base::invert is twiddling the range kind in place. You
can't do that, because you may create non-canonical ranges. Fixed by
using the canonicalizing constructor.
Committed as obvious.
commit 7a1b10ff2446e3e7800a19e8970bfe57f894cda9
Author: Aldy Hernandez
Date: Mon Nov 4
There's no need to special case pointers when converting suitable
VR_ANTI_RANGE's into VR_RANGE's now that vrp_val*{min, max} handle
pointers by default.
OK?
And now with patch!
On 11/4/19 11:15 PM, Aldy Hernandez wrote:
There's no need to special case pointers when converting suitable
VR_ANTI_RANGE's into VR_RANGE's now that vrp_val*{min, max} handle
pointers by default.
OK?
commit 2a8a783d542158405d2b90b5361669a8aa56ea83
Author:
5ca427b4558b
Author: Aldy Hernandez
Date: Mon Nov 4 21:20:26 2019 +0100
Use operand_equal_p in value_range_base::operator== so we can handle
symbolics without dying.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6fbbf87e294..3ebe7fd4348 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3
On 11/4/19 11:45 PM, Andrew MacLeod wrote:
On 11/4/19 5:23 PM, Aldy Hernandez wrote:
value_range_base::operator== was originally lifted from a world where
symbolics didn't exist (the ranger branch), but symbolics do exist in
mainline.
Although this isn't causing a problem yet,
On 11/5/19 3:55 AM, Andrew MacLeod wrote:
On 11/4/19 6:05 PM, Aldy Hernandez wrote:
On 11/4/19 11:45 PM, Andrew MacLeod wrote:
On 11/4/19 5:23 PM, Aldy Hernandez wrote:
value_range_base::operator== was originally lifted from a world
where symbolics didn't exist (the ranger branch)
This function is only used once, so there's no need for it to be
externally visible.
Committed as obvious.
commit 53363b9234db6e3b696abc53b24ea1e0d2547038
Author: Aldy Hernandez
Date: Tue Nov 5 05:10:41 2019 +0100
Move vrp_bitmap_equal_p above its only use and make it static.
nzero_bits (removed the
"P"), as it's more a value_range thing than a VRP thing.
Committed as obvious.
commit a59ec913fa95849a356d00d211510b29eab5565f
Author: Aldy Hernandez
Date: Tue Nov 5 09:48:41 2019 +0100
Move vrp_set_zero_nonzero_bits from tree-vrp.c into vr-valu
al debugging
helper.
OK for trunk?
commit cba4b59ef2e0e6821d63cfa959d201f22534eb69
Author: Aldy Hernandez
Date: Tue Nov 5 10:54:22 2019 +0100
Make range_int_cst_p work with any numeric range, not just VR_RANGE.
This includes VR_ANTI_RANGE as well as VR_VARYING, as they can also
On 11/5/19 3:27 PM, Richard Biener wrote:
On Tue, Nov 5, 2019 at 2:15 PM Aldy Hernandez wrote:
The function range_int_cst_p only works with VR_RANGE's at the moment.
This is silly because VR_ANTI_RANGE and even VR_VARYING can contain
numeric bounds. I have fixed this oversight and
Darn. I thought I had fixed all of them.
Committed as obvious.
commit 3420097161f9cdc1df27f6ffd058076df3f4f874
Author: Aldy Hernandez
Date: Tue Nov 5 17:16:47 2019 +0100
Fix indentation inconsistencies introduced by previous patch.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index
(VR_RANGE, x, y);
blah.set(VR_RANGE x, y);
Pre-approved by Andrew.
Will commit as soon as tests finish.
Aldy
commit 272ccc1bc90c551a9c550565ad200edd235c2c0e
Author: Aldy Hernandez
Date: Wed Nov 13 15:57:32 2019 +0100
Rewrite value_range constructors to the value_range_kind is at
,
predicates next, etc).
I did pull out vrp_val* and vrp_operand_equal* because value_range
depends on it. I didn't change the name to avoid churn.
OK pending tests?
Aldy
commit 8ccfc09bf5b663b1a309ea5f404b92d6bcfa0f0b
Author: Aldy Hernandez
Date: Wed Nov 13 17:17:21 2019 +0100
Move
On Mon, Apr 8, 2024 at 11:50 AM Richard Biener wrote:
>
> The following fixes ranger bitmap allocation when invoked from IPA
> context where the global bitmap obstack possibly isn't initialized.
> Instead of trying to use one of the ranger obstacks the following
> simply initializes the global bit
On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
>
> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernandez wrote:
> > > PR middle-end/114604
> > > * gimple-range.cc (enable_ranger): Initialize the global
> > > bitmap obstack.
> &
On Mon, Apr 8, 2024 at 6:29 PM Richard Biener wrote:
>
>
>
> > Am 08.04.2024 um 18:09 schrieb Aldy Hernandez :
> >
> > On Mon, Apr 8, 2024 at 5:54 PM Jakub Jelinek wrote:
> >>
> >> On Mon, Apr 08, 2024 at 05:40:23PM +0200, Aldy Hernan
bly isn't an obstack for those classes, but I
wonder if we should have a class local one, as we do for the rest of
the classes.
Aldy
On Mon, Apr 8, 2024 at 7:47 PM Richard Biener
wrote:
>
>
>
> > Am 08.04.2024 um 18:40 schrieb Aldy Hernandez :
> >
> >
The relation oracle grows the internal vector of SSAs as needed, but
due to an oversight was not growing the basic block vector. This
fixes the oversight.
OK for trunk?
PR tree-optimization/113735
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr113735.c: New test.
gcc/ChangeLog:
LGTM. Up to the release managers.
Thanks for tracking this down.
Aldy
On Tue, Feb 6, 2024 at 9:43 PM Jakub Jelinek wrote:
>
> Hi!
>
> ABSU_EXPR unary expr is special because it has a signed integer
> argument and unsigned integer result (of the same precision).
>
> The following testcase is mis
We're missing an op2_range entry for operator_not_equal so GORI can
calculate an outgoing edge. The false side of != is true and
guarantees we don't have a NAN, so it's important to get this right.
We eventually get it through an intersection of various ranges in
ranger, but it's best to get thing
We can set_nan() with a nan_state so it's good form to have the
analogous form for update_nan().
gcc/ChangeLog:
* value-range.h (frange::update_nan): New.
---
gcc/value-range.h | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/gcc/value-ra
The known_isnan() method is a subset of maybe_isnan(). This patch
removes redundant calls to known_isnan().
gcc/ChangeLog:
* range-op-float.cc (operator_lt::op1_range): Remove known_isnan check.
(operator_lt::op2_range): Same.
(operator_le::op1_range): Same.
(oper
mmitted.
Aldy
On Mon, Aug 28, 2023 at 3:01 AM Jakub Jelinek wrote:
>
> On Wed, Aug 23, 2023 at 05:22:00PM +0200, Aldy Hernandez via Gcc-patches
> wrote:
> > BTW, we batted some ideas on how to get this work, and it seems this
> > is the cleaner route with the special cases n
In coming up with testcases for the unordered folders, I realized that
we were already handling them correctly, even in the absence of my
work in this area lately.
All of the unordered fold_range() methods try to fold with the ordered
variants first, and if they return TRUE, we are guaranteed to b
On 9/20/23 11:12, Aldy Hernandez wrote:
In coming up with testcases for the unordered folders, I realized that
we were already handling them correctly, even in the absence of my
work in this area lately.
All of the unordered fold_range() methods try to fold with the ordered
variants first
In auditing the DOM code to see what the scoped tables catch that
ranger doesn't, I've run accross this test, which seems to
have uninitialized reads from both j and present[].
>From the original PR, it looks like this came from a reduction of a
failing test in SPEC's 464.h264ref. A google search
Now that the dust has settled on the prange work, we can remove the
hybrid operators. I will push this once tests complete.
gcc/ChangeLog:
* range-op-ptr.cc (class hybrid_and_operator): Remove.
(class hybrid_or_operator): Same.
(class hybrid_min_operator): Same.
(
The pointers_handled_p() method is an internal range-op helper to help
catch dispatch type mismatches for pointer operands. This is what
caught the IPA mismatch in PR114985.
This method is only a temporary measure to catch any incompatibilities
in the current pointer range-op entries. This patch
Any thoughts on this?
If no one objects, I'll re-enable prange tomorrow.
Aldy
On Sat, May 11, 2024 at 11:43 AM Aldy Hernandez wrote:
>
> I have pushed a few cleanups to make it easier to move forward without
> disturbing passes which are affected by IPA's mixing up the r
The pointers_handled_p() code was a temporary sanity check, and not
even a good one, since we have a cleaner way of checking type
mismatches with operand_check_p. This patch removes all the code, and
adds an explicit type check for relational operators, which are the
main problem in PR114985.
Add
In adding some traps for PR114985 I noticed that the conditional
folding code in simplify_using_ranges was using the wrong type. This
cleans up the oversight.
gcc/ChangeLog:
PR tree-optimization/114985
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Use
boolea
This reverts commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 and enables prange
support again.
---
gcc/gimple-range-cache.cc | 4 ++--
gcc/gimple-range-fold.cc | 4 ++--
gcc/gimple-range-fold.h | 2 +-
gcc/gimple-range-infer.cc | 2 +-
gcc/gimple-range-op.cc| 2 +-
fc3df74204c9b5e01e12f7.
etc etc.
Next time, would you like me to add manual changelog entries?
My apologies, I thought what I did was the blessed way of doing things.
Aldy
On Thu, May 16, 2024 at 12:08 PM Jakub Jelinek wrote:
>
> On Thu, May 16, 2024 at 12
Undefined ranges have no type. This patch fixes the thinko.
gcc/ChangeLog:
PR middle-end/115128
* ipa-cp.cc (ipa_value_range_from_jfunc): Check for undefined_p
before looking at type.
(propagate_vr_across_jump_function): Same.
gcc/testsuite/ChangeLog:
*
If the intersection of the bitmasks made the range span the entire
domain, normalize the range to VARYING.
gcc/ChangeLog:
PR middle-end/115131
* value-range.cc (prange::intersect): Set VARYING if intersection
of bitmasks made the range span the entire domain.
(rang
Fix a use of int_range_max in phiopt that should be a type agnostic
range, because it could be either a pointer or an int.
PR tree-optimization/115191
gcc/ChangeLog:
* tree-ssa-phiopt.cc (value_replacement): Use Value_Range instead
of int_range_max.
gcc/testsuite/ChangeL
Now that pointers and integers have been disambiguated from irange,
and all the pointer range temporaries use prange, we can reclaim
value_range as a general purpose range container.
This patch removes the typedef, in favor of int_range_max, thus
providing slightly better ranges in places. I have
[I'm slowly coming up to speed here after my absence, so please bear with me...]
I suspect there's a few things going on here, both in the forward and
the backwards threader. For the forward threader, you mention some
very good points in the PR. First, there's unnecessary recursion in
simplify_c
Now that all remaining users of value_range have been renamed to
int_range<>, we can reclaim value_range as a temporary, thus removing
the annoying CamelCase.
gcc/ChangeLog:
* data-streamer-in.cc (streamer_read_value_range): Rename
Value_Range to value_range.
* data-stream
er to get rid of
all/most of the local obstacks we use in ranger, and just use the
global (NULL) one?
Thoughts?
Aldy
On Mon, Apr 8, 2024 at 7:47 PM Richard Biener
wrote:
>
>
>
> > Am 08.04.2024 um 18:40 schrieb Aldy Hernandez :
> >
> > On Mon, Apr 8, 2024 at 6:29 PM
On 6/20/24 4:36 PM, Richard Biener wrote:
Am 20.06.2024 um 16:05 schrieb Andrew MacLeod :
On 6/20/24 05:31, Richard Biener wrote:
On Thu, 20 Jun 2024, Aldy Hernandez wrote:
Hi.
I came around to this, and whipped up the proposed patch. However, it
does seem a bit verbose, and I&#
Fix some Value_Range's that we know ahead of time will be only
integers. This avoids using the polymorphic Value_Range unnecessarily
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (check_nul_terminated_array): Make
Value_Range an int_range.
(memmodel_to_uhwi): Same
* tree-ss
Now that we have a vrange storage class to save ranges in long-term
memory, there is no need for GTY markers for any of the vrange
classes, since they should never live in GC.
gcc/ChangeLog:
* value-range-storage.h: Remove friends.
* value-range.cc (gt_ggc_mx): Remove.
(gt
Any range can theoretically have a bitmask of set bits. This patch
moves the bitmask accessors to the base class. This cleans up some
users in IPA*, and will provide a cleaner interface when prange is in
place.
gcc/ChangeLog:
* ipa-cp.cc (propagate_bits_across_jump_function): Access bit
This patch adds vrange::lbound() and vrange::ubound() that return
trees. These can be used in generic code that is type agnostic, and
avoids special casing for pointers and integers in places where we
handle both. It also cleans up a wart in the Value_Range class.
gcc/ChangeLog:
* tree-
prange will also have bitmasks, so it will need to use get_bitmask_from_range.
gcc/ChangeLog:
* value-range.cc (get_bitmask_from_range): Move out of irange class.
(irange::get_bitmask): Call function instead of internal method.
* value-range.h (class irange): Remove get_bi
Richi mentioned in PR113476 that it would be cleaner to move the
destructor from int_range to the base class. Although this isn't
strictly necessary, as there are no users, it is good to future proof
things, and the overall impact is miniscule.
gcc/ChangeLog:
* value-range.h (vrange::~vr
We have a sanity check in the irange storage code to make sure that
reading back a cache entry we have just written to yields exactly the
same range. There's no need to do this only for integers. This patch
moves the code to a more generic place.
However, doing so tickles a latent bug in the fra
Move some code out of the irange pretty printers so it can be shared
with pointers.
gcc/ChangeLog:
* value-range-pretty-print.cc (print_int_bound): New.
(print_irange_bitmasks): New.
(vrange_printer::print_irange_bound): Remove.
(vrange_printer::print_irange_bitmas
Make range_includes_zero_p take an argument instead of a pointer for
consistency in the range-op code.
gcc/ChangeLog:
* gimple-range-op.cc (cfn_clz::fold_range): Change
range_includes_zero_p argument to a reference.
(cfn_ctz::fold_range): Same.
* range-op.cc (opera
In preparation for prange, make get_legacy_range take a generic
vrange, not just an irange.
gcc/ChangeLog:
* value-range.cc (get_legacy_range): Make static and add another
version of get_legacy_range that takes a vrange.
* value-range.h (class irange): Remove unnecessary f
Explicitly make vrange an abstract class. This involves fleshing out
the unsupported_range overrides which we were inheriting by default
from vrange.
gcc/ChangeLog:
* value-range.cc (unsupported_range::accept): Move down.
(vrange::contains_p): Rename to...
(unsupported_r
Accept a vrange, as this will be used for either integers or pointers.
gcc/ChangeLog:
* value-range.h (range_includes_zero_p): Accept vrange.
---
gcc/value-range.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index ede90a4
Remove legacy range_zero and range_nonzero as they return by value,
which make it not work in a separate irange and prange world. Also,
we already have set_zero and set_nonzero methods in vrange.
gcc/ChangeLog:
* range-op-ptr.cc (pointer_plus_operator::wi_fold): Use method
range
There are some irange uses that should be Value_Range, because they
can be either integers or pointers. This will become a problem when
prange comes live.
gcc/ChangeLog:
* tree-ssa-loop-split.cc (split_at_bb_p): Make int_range a Value_Range.
* tree-ssa-strlen.cc (get_range): Same
Conditional operators are always boolean, regardless of their
operands. Getting the type wrong is not currently a problem, but will
be when prange's can no longer store an integer.
gcc/ChangeLog:
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Remove
type from range_t
As per the documentation, irange_bitmask must have the unknown bits in
the mask set to 0 in the value field. Even though we say we must have
normalized value/mask bits, we don't enforce it, opting to normalize
on the fly in union and intersect. Avoiding this lazy enforcing as
well as the extra sa
lease, so they should be safe to push now.
There should be no change in behavior in any of these patches.
All patches have been tested on x86-64 Linux.
Aldy Hernandez (16):
Make vrange an abstract class.
Add a virtual vrange destructor.
Make some Value_Range's explicitly integer.
The polymorphic Value_Range object takes a tree type at construction
so it can determine what type of range to use (currently irange or
frange). It seems a few of the types are slightly off. This isn't a
problem now, because IPA only cares about integers and pointers, which
can both live in an ir
Ughhh, you're right. Thanks for spotting this.
I'm testing the attached patch and will commit if it passes tests.
Aldy
On Tue, Apr 30, 2024 at 9:46 AM Richard Biener
wrote:
>
> On Sun, Apr 28, 2024 at 9:07 PM Aldy Hernandez wrote:
> >
> > Fix some Value_Range&
Here are some cleanups to unsupported_range so the assignment operator
takes an unsupported_range and behaves like the other ranges. This
makes subsequent cleanups easier.
gcc/ChangeLog:
* value-range.cc (unsupported_range::union_): Cast vrange to
unsupported_range.
(unsu
Value_Range is our polymorphic temporary that can hold any range. It
is used for type agnostic code where it isn't known ahead of time,
what the type of the range will be (irange, france, etc). Currently,
there is a temporary of each type in the object, which means we need
to construct each range
Sparc requires strict alignment and is choking on the byte vector in
Value_Range. Is this the right approach, or is there a more canonical
way of forcing alignment?
If this is correct, OK for trunk?
gcc/ChangeLog:
* value-range.h (class Value_Range): Use a union.
---
gcc/value-range.h
gt;
> On Fri, May 3, 2024 at 2:24 AM Aldy Hernandez wrote:
> >
> > Sparc requires strict alignment and is choking on the byte vector in
> > Value_Range. Is this the right approach, or is there a more canonical
> > way of forcing alignment?
>
> I think the suggesti
u.org/pipermail/gcc-patches/2024-May/650320.html
So things are looking relatively good.
The memory usage will also decrease, both by the 14% reduction in
Value_Range, and by prange's being smaller than say int_range_max or
int_range<3>.
Tested and benchmarked on x86-64 Linux.
Al
gcc/ChangeLog:
* data-streamer-in.cc (streamer_read_value_range): Add prange support.
* data-streamer-out.cc (streamer_write_vrange): Same.
---
gcc/data-streamer-in.cc | 12
gcc/data-streamer-out.cc | 10 ++
2 files changed, 22 insertions(+)
diff --git a/gcc
gcc/ChangeLog:
* value-range-storage.cc (vrange_allocator::clone_varying): Add
prange support.
(vrange_allocator::clone_undefined): Same.
(vrange_storage::alloc): Same.
(vrange_storage::set_vrange): Same.
(vrange_storage::get_vrange): Same.
(
This provides a bare prange class with bounds and bitmasks. It will
be a drop-in replacement for pointer ranges, so we can pull their
support from irange. The range-op code will be contributed as a
follow-up.
The code is disabled by default, as irange::supports_p still accepts
pointers:
inline
This patch adds the range-op dispatch code for prange, and adds some
temporary sanity checks (for flag_checking only) to make sure we handle
all the pointer/integer variants.
In order to make sure I got all the combinations right, I started with
a clean slate, trapping on all pointer operands. Th
1 - 100 of 2312 matches
Mail list logo
