Re: [RFC] > WIDE_INT_MAX_PREC support in wide_int and widest_int

2023-09-29 Thread Aldy Hernandez
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

Re: [PATCH] ipa: Remove ipa_bits

2023-10-05 Thread Aldy Hernandez
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

Re: [patch] jump threading multiple paths that start from the same BB

2018-07-03 Thread Aldy Hernandez
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

Re: extract_range_from_binary* cleanups for VRP

2018-07-03 Thread Aldy Hernandez
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

Re: [patch] jump threading multiple paths that start from the same BB

2018-07-04 Thread Aldy Hernandez
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

calculate overflow type in wide int arithmetic

2018-07-05 Thread Aldy Hernandez
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

Re: calculate overflow type in wide int arithmetic

2018-07-06 Thread Aldy Hernandez
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

Re: [patch] jump threading multiple paths that start from the same BB

2018-07-09 Thread Aldy Hernandez
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

Re: [patch] jump threading multiple paths that start from the same BB

2018-07-09 Thread Aldy Hernandez
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

Re: [PATCH] add support for strnlen (PR 81384)

2018-07-09 Thread Aldy Hernandez
{ 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

Re: calculate overflow type in wide int arithmetic

2018-07-09 Thread Aldy Hernandez
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

abstract wide int binop code from VRP

2018-07-10 Thread Aldy Hernandez
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

Re: [patch] jump threading multiple paths that start from the same BB

2018-07-10 Thread Aldy Hernandez
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

abstract gimple_call_nonnull*() from vr-values

2018-07-10 Thread Aldy Hernandez
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

allow thread_through_all_blocks() to start from the same initial BB

2018-07-10 Thread Aldy Hernandez
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

Re: abstract wide int binop code from VRP

2018-07-10 Thread Aldy Hernandez
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

Re: abstract wide int binop code from VRP

2018-07-11 Thread Aldy Hernandez
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

Re: abstract wide int binop code from VRP

2018-07-12 Thread Aldy Hernandez
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

Re: abstract wide int binop code from VRP

2018-07-12 Thread Aldy Hernandez
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

Re: abstract wide int binop code from VRP

2018-07-13 Thread Aldy Hernandez
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_

cleanup cross product code in VRP

2018-07-16 Thread Aldy Hernandez
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

Re: cleanup cross product code in VRP

2018-07-18 Thread Aldy Hernandez
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

Re: cleanup cross product code in VRP

2018-07-19 Thread Aldy Hernandez
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

abstract remaining wide int operations in VRP

2018-07-30 Thread Aldy Hernandez
...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

[COMMITTED] [range-ops] Remove unneeded parameters from rv_fold.

2023-10-26 Thread Aldy Hernandez
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

[COMMITTED] [range-ops] Add frange& argument to rv_fold.

2023-10-26 Thread Aldy Hernandez
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

[PATCH] [range-op] Remove unused variable in fold_range.

2023-10-26 Thread Aldy Hernandez
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

[committed] add debugging routines for assert_info structure

2019-11-04 Thread Aldy Hernandez
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-

[committed] handle VR_UNDEFINED in normalize_addresses

2019-11-04 Thread Aldy Hernandez
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

[committed] remove unused range_int_cst_singleton_p

2019-11-04 Thread Aldy Hernandez
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

always handle pointers in vrp_val*{min,max}

2019-11-04 Thread Aldy Hernandez
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

[committed] do not create non-canonical ranges in value_range_base::invert

2019-11-04 Thread Aldy Hernandez
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

do not special case pointers while canonicalizing ranges

2019-11-04 Thread Aldy Hernandez
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?

Re: do not special case pointers while canonicalizing ranges

2019-11-04 Thread Aldy Hernandez
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:

handle symbolics when comparing ranges

2019-11-04 Thread Aldy Hernandez
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

Re: handle symbolics when comparing ranges

2019-11-04 Thread Aldy Hernandez
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,

Re: handle symbolics when comparing ranges

2019-11-04 Thread Aldy Hernandez
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)

[committed] make vrp_bitmap_equal_p static

2019-11-04 Thread Aldy Hernandez
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.

[committed] move vrp_set_zero_nonzero_bits into vr-values.c

2019-11-05 Thread Aldy Hernandez
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

make range_int_cst_p work with any numeric range (VR_ANTI_RANGE, etc)

2019-11-05 Thread Aldy Hernandez
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

Re: make range_int_cst_p work with any numeric range (VR_ANTI_RANGE, etc)

2019-11-05 Thread Aldy Hernandez
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

[committed] fix indentation issues with value_range_equiv patch

2019-11-05 Thread Aldy Hernandez
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

[committed] place value_range_kind at the end of value_range constructors

2019-11-13 Thread Aldy Hernandez
(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

extract independent value_range bits to value-range.cc

2019-11-13 Thread Aldy Hernandez
, 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

Re: [PATCH] middle-end/114604 - ranger allocates bitmap without initialized obstack

2024-04-08 Thread Aldy Hernandez
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

Re: [PATCH] middle-end/114604 - ranger allocates bitmap without initialized obstack

2024-04-08 Thread 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 Hernandez wrote: > > > PR middle-end/114604 > > > * gimple-range.cc (enable_ranger): Initialize the global > > > bitmap obstack. > &

Re: [PATCH] middle-end/114604 - ranger allocates bitmap without initialized obstack

2024-04-08 Thread Aldy Hernandez
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

Re: [PATCH] middle-end/114604 - ranger allocates bitmap without initialized obstack

2024-04-08 Thread Aldy Hernandez
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 : > > > > 

[PATCH] ranger: Grow BBs in relation oracle as needed [PR113735]

2024-02-06 Thread 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:

Re: [PATCH] range-op: Fix up ABSU_EXPR handling [PR113756]

2024-02-07 Thread Aldy Hernandez
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

[COMMITTED] [frange] Add op2_range for operator_not_equal.

2023-09-19 Thread Aldy Hernandez
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

gcc-patches@gcc.gnu.org

2023-09-19 Thread Aldy Hernandez
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

[COMMITTED] [frange] Remove redundant known_isnan() checks.

2023-09-19 Thread Aldy Hernandez
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

Re: [PATCH] [frange] Relax floating point relational folding.

2023-09-19 Thread Aldy Hernandez
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

[PATCH] [frange] Remove special casing from unordered operators.

2023-09-20 Thread Aldy Hernandez
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

Re: [PATCH] [frange] Remove special casing from unordered operators.

2023-09-20 Thread Aldy Hernandez
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

[PATCH] [testsuite] Remove undefined behavior from gcc.dg/tree-ssa/pr44306.c

2023-09-25 Thread Aldy Hernandez
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

[PATCH] Remove unused hybrid_* operators in range-ops.

2024-06-28 Thread Aldy Hernandez
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. (

[COMMITTED] [prange] Default pointers_handled_p() to false.

2024-05-15 Thread Aldy Hernandez
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

Re: [PATCH] Adjust range type of calls into fold_range for IPA passes [PR114985]

2024-05-15 Thread Aldy Hernandez
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

[COMMITTED] Cleanup prange sanity checks.

2024-05-16 Thread Aldy Hernandez
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

[COMMITTED] Use a boolean type when folding conditionals in simplify_using_ranges.

2024-05-16 Thread Aldy Hernandez
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

[COMMITTED] Revert "Revert: "Enable prange support.""

2024-05-16 Thread Aldy Hernandez
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 +-

Re: [COMMITTED] Revert "Revert: "Enable prange support.""

2024-05-16 Thread Aldy Hernandez
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

[COMMITTED] [prange] Avoid looking at type() for undefined ranges

2024-05-17 Thread Aldy Hernandez
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: *

[COMMITTED] [prange] Drop range to VARYING if the bitmask intersection made it so [PR115131]

2024-05-17 Thread Aldy Hernandez
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

[COMMITTED] [prange] Use type agnostic range in phiopt [PR115191]

2024-05-22 Thread Aldy Hernandez
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

[COMMITTED] Remove value_range typedef.

2024-06-03 Thread Aldy Hernandez
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

Re: [PATCH] tree-optimization/116166 - forward jump-threading going wild

2024-08-25 Thread Aldy Hernandez
[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

[COMMITTED] Rename Value_Range to value_range.

2024-06-17 Thread Aldy Hernandez
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

Re: [PATCH] middle-end/114604 - ranger allocates bitmap without initialized obstack

2024-06-20 Thread Aldy Hernandez
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

Re: [PATCH] middle-end/114604 - ranger allocates bitmap without initialized obstack

2024-06-26 Thread Aldy Hernandez
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&#

[COMMITTED 03/16] Make some Value_Range's explicitly integer.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 06/16] Remove GTY support for vrange and derived classes.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 05/16] Move bitmask routines to vrange base class.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 04/16] Add tree versions of lower and upper bounds to vrange.

2024-04-28 Thread Aldy Hernandez
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-

[COMMITTED 11/16] Move get_bitmask_from_range out of irange class.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 02/16] Add a virtual vrange destructor.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 09/16] Verify that reading back from vrange_storage doesn't drop bits.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 14/16] Move print_irange_* out of vrange_printer class.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 08/16] Change range_includes_zero_p argument to a reference.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 10/16] Accept a vrange in get_legacy_range.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 01/16] Make vrange an abstract class.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 13/16] Accept any vrange in range_includes_zero_p.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 15/16] Remove range_zero and range_nonzero.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 12/16] Make some integer specific ranges generic Value_Range's.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 07/16] Make fold_cond_with_ops use a boolean type for range_true/range_false.

2024-04-28 Thread Aldy Hernandez
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

[COMMITTED 16/16] Callers of irange_bitmask must normalize value/mask pairs.

2024-04-28 Thread Aldy Hernandez
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

[PATCH 00/16] prange supporting patchset

2024-04-28 Thread Aldy Hernandez
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.

[PATCH] Minor range type fixes for IPA in preparation for prange.

2024-04-28 Thread Aldy Hernandez
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

Re: [COMMITTED 03/16] Make some Value_Range's explicitly integer.

2024-04-30 Thread Aldy Hernandez
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&

[COMMITTED] Cleanups to unsupported_range.

2024-05-01 Thread Aldy Hernandez
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

[COMMITTED] Reduce startup costs for Value_Range.

2024-05-01 Thread Aldy Hernandez
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

[PATCH] [ranger] Force buffer alignment in Value_Range [PR114912]

2024-05-03 Thread Aldy Hernandez
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

Re: [PATCH] [ranger] Force buffer alignment in Value_Range [PR114912]

2024-05-03 Thread Aldy Hernandez
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

[PATCH 00/23] prange: pointer ranges

2024-05-04 Thread Aldy Hernandez
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

[COMMITTED 03/23] Add streaming support for prange.

2024-05-04 Thread Aldy Hernandez
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

[COMMITTED 04/23] Add storage support for prange.

2024-05-04 Thread Aldy Hernandez
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. (

[COMMITTED 02/23] Implement basic prange class.

2024-05-04 Thread Aldy Hernandez
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

[COMMITTED 07/23] Implement range-op dispatch for prange.

2024-05-04 Thread Aldy Hernandez
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   2   3   4   5   6   7   8   9   10   >