diff options
author | Aldy Hernandez <aldyh@redhat.com> | 2022-06-10 15:11:06 +0200 |
---|---|---|
committer | Aldy Hernandez <aldyh@redhat.com> | 2022-07-11 08:30:40 +0200 |
commit | 0a7e721a6499a42f04361caf24772547afdeed57 (patch) | |
tree | a6d9dd193377ac9d0c450b9af1d3965c10da587b /gcc/tree-vrp.cc | |
parent | b53ebbc5417d522b820c269aee0d080bb2b27212 (diff) | |
download | gcc-0a7e721a6499a42f04361caf24772547afdeed57.zip gcc-0a7e721a6499a42f04361caf24772547afdeed57.tar.gz gcc-0a7e721a6499a42f04361caf24772547afdeed57.tar.bz2 |
Implement global ranges for all vrange types (SSA_NAME_RANGE_INFO).
Currently SSA_NAME_RANGE_INFO only handles integer ranges, and loses
half the precision in the process because its use of legacy
value_range's. This patch rewrites all the SSA_NAME_RANGE_INFO
(nonzero bits included) to use the recently contributed
vrange_storage. With it, we'll be able to efficiently save any ranges
supported by ranger in GC memory. Presently this will only be
irange's, but shortly we'll add floating ranges and others to the mix.
As per the discussion with the trailing_wide_ints adjustments and
vrange_storage, we'll be able to save integer ranges with a maximum of
5 sub-ranges. This could be adjusted later if more sub-ranges are
needed (unlikely).
Since this is a behavior changing patch, I would like to take a few
days for discussion, and commit early next week if all goes well.
A few notes.
First, we get rid of the SSA_NAME_ANTI_RANGE_P bit in the SSA_NAME
since we store full resolution ranges. Perhaps it could be re-used
for something else.
The range_info_def struct is gone in favor of an opaque type handled
by vrange_storage. It currently supports irange, but will support
frange, prange, etc, in due time.
From the looks of it, set_range_info was an update operation despite
its name, as we improved the nonzero bits with each call, even though
we clobbered the ranges. Presumably this was because doing a proper
intersect of ranges lost information with the anti-range hack. We no
longer have this limitation so now we formalize both set_range_info
and set_nonzero_bits to an update operation. After all, we should
never be losing information, but enhancing it whenever possible. This
means, that if folks' finger-memory is not offended, as a follow-up,
I'd like to rename set_nonzero_bits and set_range_info to update_*.
I have kept the same global API we had in tree-ssanames.h, with the
caveat that all set operations are now update as discussed above.
There is a 2% performance penalty for evrp and a 3% penalty for VRP
that is coincidentally in line with a previous improvement of the same
amount in the vrange abstraction patchset. Interestingly, this
penalty is mostly due to the wide int to tree dance we keep doing with
irange and legacy. In a first draft of this patch where I was
streaming trees directly, there was actually a small improvement
instead. I hope to get some of the gain back when we move irange's to
wide-ints, though I'm not in a hurry ;-).
Tested and benchmarked on x86-64 Linux. Tested on ppc64le Linux.
Comments welcome.
gcc/ChangeLog:
* gimple-range.cc (gimple_ranger::export_global_ranges): Remove
verification against legacy value_range.
(gimple_ranger::register_inferred_ranges): Same.
(gimple_ranger::export_global_ranges): Rename update_global_range
to set_range_info.
* tree-core.h (struct range_info_def): Remove.
(struct irange_storage_slot): New.
(struct tree_base): Remove SSA_NAME_ANTI_RANGE_P documentation.
(struct tree_ssa_name): Add vrange_storage support.
* tree-ssanames.cc (range_info_p): New.
(range_info_fits_p): New.
(range_info_alloc): New.
(range_info_free): New.
(range_info_get_range): New.
(range_info_set_range): New.
(set_range_info_raw): Remove.
(set_range_info): Adjust to use vrange_storage.
(set_nonzero_bits): Same.
(get_nonzero_bits): Same.
(duplicate_ssa_name_range_info): Remove overload taking
value_range_kind.
Rewrite tree overload to use vrange_storage.
(duplicate_ssa_name_fn): Adjust to use vrange_storage.
* tree-ssanames.h (struct range_info_def): Remove.
(set_range_info): Adjust prototype to take vrange.
* tree-vrp.cc (vrp_asserts::remove_range_assertions): Call
duplicate_ssa_name_range_info.
* tree.h (SSA_NAME_ANTI_RANGE_P): Remove.
(SSA_NAME_RANGE_TYPE): Remove.
* value-query.cc (get_ssa_name_range_info): Adjust to use
vrange_storage.
(update_global_range): Remove.
(get_range_global): Remove as_a<irange>.
* value-query.h (update_global_range): Remove.
* tree-ssa-dom.cc (set_global_ranges_from_unreachable_edges):
Rename update_global_range to set_range_info.
* value-range-storage.cc (vrange_storage::alloc_slot): Remove
gcc_unreachable.
Diffstat (limited to 'gcc/tree-vrp.cc')
-rw-r--r-- | gcc/tree-vrp.cc | 22 |
1 files changed, 12 insertions, 10 deletions
diff --git a/gcc/tree-vrp.cc b/gcc/tree-vrp.cc index ed881be..c3030a1 100644 --- a/gcc/tree-vrp.cc +++ b/gcc/tree-vrp.cc @@ -3739,16 +3739,18 @@ vrp_asserts::remove_range_assertions () && all_imm_uses_in_stmt_or_feed_cond (var, stmt, single_pred (bb))) { - /* We could use duplicate_ssa_name_range_info here - instead of peeking inside SSA_NAME_RANGE_INFO, - but the aforementioned asserts that the - destination has no global range. This is - slated for removal anyhow. */ - value_range r (TREE_TYPE (lhs), - SSA_NAME_RANGE_INFO (lhs)->get_min (), - SSA_NAME_RANGE_INFO (lhs)->get_max (), - SSA_NAME_RANGE_TYPE (lhs)); - set_range_info (var, r); + if (SSA_NAME_RANGE_INFO (var)) + { + /* ?? This is a minor wart exposing the + internals of SSA_NAME_RANGE_INFO in order + to maintain existing behavior. This is + because duplicate_ssa_name_range_info below + needs a NULL destination range. This is + all slated for removal... */ + ggc_free (SSA_NAME_RANGE_INFO (var)); + SSA_NAME_RANGE_INFO (var) = NULL; + } + duplicate_ssa_name_range_info (var, lhs); maybe_set_nonzero_bits (single_pred_edge (bb), var); } } |