Jan Hubicka writes:
>> > 2024-11-01 Martin Jambor
>> >
>> > * ipa-prop.cc (ipa_compute_jump_functions_for_edge): When creating
>> > value-range jump functions from pointer type constant zero, do so
>> > as if it was not a pointer.
>> > ---
>> > gcc/ipa-prop.cc | 3 ++-
Aldy Hernandez writes:
> Martin Jambor writes:
>
>> Hi,
>>
>> Because the simplified way of extracting value ranges from functions
>> does not look at scalar constants (as one of the versions had been
>> doing before) but instead rely on the value range
Andrew Carlotti writes:
> This test started failing on aarch64 after 0cfc9c95 in 2023 ("Phi
> analyzer - Initialize with range instead of a tree.").
>
> The only change visible in the pass dumps prior to thread2 is the upper
> bounds of some ranges are reduced from +INF to 7, consistent with the
Martin Jambor writes:
> Hi,
>
> Because the simplified way of extracting value ranges from functions
> does not look at scalar constants (as one of the versions had been
> doing before) but instead rely on the value range within the jump
> function already capturing the constant, I have added a v
Martin Jambor writes:
> Hi,
>
> currently ipa_value_range_from_jfunc and
> propagate_vr_across_jump_function contain similar but not same code
> for dealing with pass-through jump functions. This patch puts these
> common bits into one function which can also handle comparison
> operations.
>
>
Martin Jambor writes:
> +/* If T is an SSA_NAME that is a result of a simple type conversion
> statement,
I think "the result" sounds better than "a result", assuming there is
just one result.
> + return the operand of that conversion, otherwise treturn T. */
s/treturn/return/
Aldy
Richard Biener writes:
> The following reduces the number of wide_ints built which show up
> in the profile for PR114855 as the largest remaining bit at -O1.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Thanks.
Pushed attached patch.
Thanks.
Aldy
On Tue, Sep 24, 2024 at 10:09 AM Filip Kastl wrote:
> On Mon 2024-09-23 09:43:28, Aldy Hernandez wrote:
> > From: Aldy Hernandez
> >
> > ChangeLog:
> >
> > * MAINTAINERS: Update email and add myself to
From: Aldy Hernandez
ChangeLog:
* MAINTAINERS: Update email and add myself to DCO.
---
MAINTAINERS | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cfd96c9f33e..e9fafaf45a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -116,7
Ok
On Thu, Sep 5, 2024, 09:30 Jakub Jelinek wrote:
> Hi!
>
> I've noticed non-standard wording of this diagnostics when looking at
> a miscompilation with --param=vrp-block-limit=0.
>
> Diagnostics generally shouldn't start with uppercase letter (unless
> the upper case would appear also in the
[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 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.
(
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&#
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
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
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
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
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
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:
*
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
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 +-
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
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
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() 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
On Thu, May 9, 2024 at 10:05 AM Mikael Morin wrote:
>
> Hello,
>
> Le 07/05/2024 à 04:37, HAO CHEN GUI a écrit :
> > Hi,
> >The former patch adds isfinite optab for __builtin_isfinite.
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
> >
> >Thus the builtin might not be
o, for the above 4 architectures things work as before, and we have a
PR to track the IPA problem which doesn't seem to affect neither
bootstrap nor tests.
Does this sound reasonable?
Aldy
On Fri, May 10, 2024 at 12:26 PM Richard Biener
wrote:
>
> On Fri, May 10, 2024 at 11:24 AM
For the record, we have always returned false (VARYING) for
unsupported range operators. This patch just restores the behavior
we've always had, while adding a knob for further analysis (for
example. IPA which is getting its range types mixed up).
Aldy
On Sat, May 11, 2024 at 11:28 AM
The canonical way to indicate that a range operator is unsupported is
to return false, which has the sematic meaning of VARYING. This patch
cleans up a few default virtuals that were trying harder to set
VARYING manually.
gcc/ChangeLog:
* range-op-ptr.cc (range_operator::fold_range): Ret
The trap in the range-op dispatch code is really an internal debugging
aid, and only a temporary one for a few weeks while the dust settles.
This patch turns it off by default, allowing problematic passes to
turn it on for analysis.
gcc/ChangeLog:
* range-op.cc (TRAP_ON_UNHANDLED_POINTER_
gcc/ChangeLog:
PR tree-optimization/115026
* value-range.cc (prange::update_bitmask): Use operand bitmask.
---
gcc/value-range.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 3e1ecf69517..5bcb2c3f650 100644
--- a
I would much prefer the IPA experts to fix the pass, but I'm afraid I
don't understand the code enough to do so.
Could someone lend a hand here?
Aldy
On Fri, May 10, 2024 at 12:26 PM Richard Biener
wrote:
>
> On Fri, May 10, 2024 at 11:24 AM Aldy Hernandez wrote:
> >
There are various calls into fold_range() that have the wrong type
associated with the range temporary used to hold the result. This
used to work, because we could store either integers or pointers in a
Value_Range, but is no longer the case with prange's. Now you must
explicitly state which type
In a world with same sized pointers we can always reuse the storage
slots, but since this is not always the case, we need to be more
careful. However, we can always store an undefined, because that
requires no extra storage.
gcc/ChangeLog:
PR tree-optimization/115009
* value-rang
This reverts commit 36e877996936abd8bd08f8b1d983c8d1023a5842 until the IPA
pass is fixed with regards to POINTER = POINTER POINTER.
---
gcc/gimple-range-cache.cc | 4 ++--
gcc/gimple-range-fold.cc | 4 ++--
gcc/gimple-range-fold.h | 2 +-
gcc/gimple-range-infer.cc | 2 +-
This is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
I have proposed a patch but need confirmation from the IPA folks.
Aldy
On Thu, May 9, 2024 at 10:08 AM Andreas Schwab wrote:
>
> Breaks bootstrap on aarch64.
>
> $ /opt/gcc/gcc-20240509/Build/./prev-gcc/xg++
> -B/opt/gcc/gcc-20240509
Pushed to trunk to unblock sparc.
On Fri, May 3, 2024 at 4:24 PM Aldy Hernandez wrote:
>
> Ahh, that is indeed cleaner, and there's no longer a need to assert
> the sizeof of individual ranges.
>
> It looks like a default constructor is needed for the buffer now, but
&g
After reading the ICE for the PR, it's obvious the error message is
rather cryptic. This makes it less so.
gcc/ChangeLog:
* range-op.cc (range_op_handler::discriminator_fail): Reword error
message.
---
gcc/range-op.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
I'll defer to the PPC maintainers, but LGTM. The less special casing, the
better.
Aldy
On Wed, May 8, 2024, 07:33 Kewen.Lin wrote:
> Hi,
>
> This reverts commit r14-6478-gfda8e2f8292a90 "range:
> Workaround different type precision between _Float128 and
> long double [PR112788]" as the fixes fo
This throws the switch on prange. After this patch, it is no longer
valid to store a pointer in an irange (or vice versa). Instead, they
must go in prange, which is faster and more memory efficient.
I will push this now, so I have time to do any follow-up bugfixing
before going on paternity leav
Pushed to trunk.
On Sun, Apr 28, 2024 at 10:10 PM Aldy Hernandez wrote:
>
> 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&#
PING.
I can probably commit this patchlet as a ranger maintainer, but I'd
prefer a nod from a global or IPA maintainer. It is the one patch
that's needed before I can throw the switch on prange support later
this week.
Thanks.
Aldy
On Sun, Apr 28, 2024 at 10:10 PM Aldy Hernan
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_gt::fold_range): New.
(operator_gt::op1_range): New.
(operator_gt::op2_range): New.
(operator_gt::op1_op2_relation): New.
(operator_gt::p
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_equal::fold_range): New.
(operator_equal::op1_range): New.
(operator_equal::op2_range): New.
(operator_equal::op1_op2_relation): New.
(op
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_ge::fold_range): New.
(operator_ge::op1_range): New.
(operator_ge::op2_range): New.
(operator_ge::op1_op2_relation): New.
(operator_ge::p
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for fold_range,
op1_range,
lhs_op1_relation, pointers_handled_p.
* range-op-ptr.cc (operator_identity::fold_range): New.
(operator_identity::lhs_op1_relation): New.
(operator_identity::op1_range
gcc/ChangeLog:
* range-op-ptr.cc
(operator_pointer_diff::op1_op2_relation_effect): New.
(operator_pointer_diff::pointers_handled_p): New.
---
gcc/range-op-ptr.cc | 32
1 file changed, 32 insertions(+)
diff --git a/gcc/range-op-ptr.cc b/gcc
gcc/ChangeLog:
* gimple-range-op.cc (class cfn_pass_through_arg1): Add overloads
for prange operations.
(cfn_strlen): Same.
---
gcc/gimple-range-op.cc | 36
1 file changed, 36 insertions(+)
diff --git a/gcc/gimple-range-op.cc b/gcc/gim
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_le::fold_range): New.
(operator_le::op1_range): New.
(operator_le::op2_range): New.
(operator_le::op1_op2_relation): New.
(operator_le::p
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_min::fold_range): New.
(operator_min::pointers_handled_p): New.
(operator_max::fold_range): New.
(operator_max::pointers_handled_p): New.
---
gc
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_cst::fold_range): New.
(operator_cst::pointers_handled_p): New.
---
gcc/range-op-mixed.h | 4
gcc/range-op-ptr.cc | 23 +++
2 files c
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_not_equal::fold_range): New.
(operator_not_equal::op1_range): New.
(operator_not_equal::op2_range): New.
(operator_not_equal::op1_op2_relation):
gcc/ChangeLog:
* value-range.cc (get_legacy_range): New version for prange.
---
gcc/value-range.cc | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 62170a438bf..3e1ecf69517 100644
--- a/g
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (max_limit): New.
(min_limit): New.
(build_lt): New.
(build_le): New.
(build_gt): New.
(build_ge): New.
(operator_lt::fold_range):
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_addr_expr::op1_range): New.
(operator_addr_expr::pointers_handled_p): New.
---
gcc/range-op-mixed.h | 4
gcc/range-op-ptr.cc | 38 +++
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_cast::fold_range): New.
(operator_cast::op1_range): New.
(operator_cast::lhs_op1_relation): New.
(operator_cast::pointers_handled_p): New.
---
g
gcc/ChangeLog:
* range-op-ptr.cc (class pointer_plus_operator): Add overloaded
declarations
for pointer variants.
(pointer_plus_operator::fold_range): New.
(pointer_plus_operator::op2_range): New.
(pointer_plus_operator::pointers_handled_p): New.
---
gcc/r
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
* range-op-ptr.cc (operator_bitwise_and::fold_range): New.
(operator_bitwise_and::pointers_handled_p): New.
---
gcc/range-op-mixed.h | 6 ++
gcc/range-op-ptr.cc | 30
We seem to have a range-op entry for pointer bitwise OR that we've
inherited from the original VRP implementation, but it never gets
used. If this is not valid gimple, we can safely remove this entry.
gcc/ChangeLog:
* range-op-mixed.h: Add overloaded declarations for pointer variants.
gcc/ChangeLog:
* value-range.cc (add_vrange): Add prange support.
---
gcc/value-range.cc | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 84113ccfbd0..62170a438bf 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@
There is a 2% slowdown to VRP unrelated to the work at hand. This patch
is a skeleton implementation of prange that exhibits this degradation. It
is meant as a place in the commit history we can return to in order to revisit
the issue.
The relevant discussion is here:
https://gcc.gnu.org/piperm
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
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
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.
(
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
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
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
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
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
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&
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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-
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
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
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
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 :
> >
> >
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
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 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
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
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:
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
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
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
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 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
1 - 100 of 1010 matches
Mail list logo
