diff options
author | Aldy Hernandez <aldyh@redhat.com> | 2022-07-01 13:20:42 +0200 |
---|---|---|
committer | Aldy Hernandez <aldyh@redhat.com> | 2022-07-04 11:34:20 +0200 |
commit | 4e82205b68024f5c1a9006fe2b62e1a0fa7f1245 (patch) | |
tree | 77cebaa3afd64005e885a7660996b11fa753eda8 /gcc/tree-vectorizer.h | |
parent | d2a898666609452ef79a14feae1cadc3538e4b45 (diff) | |
download | gcc-4e82205b68024f5c1a9006fe2b62e1a0fa7f1245.zip gcc-4e82205b68024f5c1a9006fe2b62e1a0fa7f1245.tar.gz gcc-4e82205b68024f5c1a9006fe2b62e1a0fa7f1245.tar.bz2 |
Integrate nonzero bits with irange.
The nonzero bits and integer ranges compliment each other quite well,
and it only makes sense to make the mask a first class citizen in the
irange. We do a half assed job of keeping ranges and nonzero bits
somewhat in sync in SSA_NAME_RANGE_INFO, and the goal has always
been to integrate them properly. This patch does that, in preparation
for streaming out full-resolution iranges between passes (think
SSA_NAME_RANGE_INFO).
Having nonzero bits in the irange allows us to get better results from
things like irange::contains_p() and keeping them in the irange allows
us to propagate the bits throughout with the ranger. This patch
provides the bare infrastructure, without any optimizations to
range-ops, etc. Those will come as follow-ups.
A few notes:
Legacy SSA_NAME_RANGE_INFO updates the nonzero bits every time a range
is set. Here instead, we don't update the nonzero bits on a new
range, but calculate it on the fly when irange::get_nonzero_bits() is
called. The goal is to only store nonzero bits that provide
meaningful information that can't be gleaned from the range itself.
But you can always call get_nonzero_bits() and get the full
information.
Nonzero bits are not supported in legacy mode. The mask may be set
as a consequence of propagation or reading global ranges, but no
one from legacy land should be querying irange::get_nonzero_bits. There
is an assert enforcing this. However, legacy/global set_nonzero_bits()
continue to work as before. There is no change to legacy behavior.
There is virtually no performance change with this patch, as there are
no consumers. The next patch I post will be the SSA_NAME_RANGE_INFO
conversion to the new world, in which I will discuss performance
proper. Hint: I'll be chewing up the time budget we gained with the
vrange conversion.
Tested and benchmarked on x86-64 Linux.
gcc/ChangeLog:
* value-range-storage.cc (irange_storage_slot::set_irange): Set
nonzero bits in irange.
(irange_storage_slot::get_irange): Get nonzero bits from irange.
* value-range.cc (irange::operator=): Set nonzero bits.
(irange::irange_set): Same.
(irange::irange_set_anti_range): Same.
(irange::set): Same.
(irange::verify_range): Same.
(irange::legacy_equal_p): Check nonzero bits.
(irange::equal_p): Same.
(irange::contains_p): Handle nonzero bits.
(irange::irange_union): Same.
(irange::irange_intersect): Same.
(irange::dump): Same.
(irange::set_nonzero_bits): New.
(irange::get_nonzero_bits): New.
(irange::intersect_nonzero_bits): New.
(irange::union_nonzero_bits): New.
(irange::dump_bitmasks): New.
* value-range.h (class irange): Add m_nonzero_mask.
(gt_ggc_mx): Handle nonzero bits.
(gt_pch_nx): Same.
(irange::set_undefined): Set nonzero bits.
(irange::set_varying): Same.
(irange::normalize_kind): Call set_undefined.
Diffstat (limited to 'gcc/tree-vectorizer.h')
0 files changed, 0 insertions, 0 deletions