Folks. I have decided to put this aside until the next release. I originally wanted a simple rename, and reimplementing things to align with rtl, etc, is beyond what I want to tackle on this late.
I'll archive this away, and revisit it when we implement the irange::known_ones mask. Thanks for your input. Aldy On Fri, Oct 21, 2022 at 8:01 PM Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > On Fri, Oct 21, 2022 at 06:54:32PM +0200, Jakub Jelinek wrote: > > On Fri, Oct 21, 2022 at 06:51:19PM +0200, Jakub Jelinek wrote: > > > Agreed. > > > > > > I think maybe_nonzero_bits would be fine. > > > > Or yet another option is to change what we track and instead of > > having just one bitmask have 2 as tree-ssa-ccp.cc does, > > one bitmask says which bits are known to be always the same > > and the other which specifies the values of those bits. > > "For X with a CONSTANT lattice value X & ~mask == value & ~mask. The > > zero bits in the mask cover constant values. The ones mean no > > information." > > I am still working on making the RTL nonzero_bits use DF (and indeed I > do a known_zero instead :-) ). This makes the special version in > combine unnecessary: instead of working better than the generic version > it is strictly weaker then. This change then makes it possible to use > nonzero_bits in instruction conditions (without causing ICEs as now -- > passes after combine return a subset of the nonzero_bits the version in > combine does, which can make insns no longer match in later passes). > > My fear is tracking twice as many bits might become expensive. OTOH > ideally we can get rid of combine's reg_stat completely at some point > in the future (which has all the same problems as combine's version of > nonzero_bits: the values it returns depend on the order combine tried > possible combinations). > > Storage requirements are the same for known_zero_bits and known_one_bits > vs. known_bits and known_bit_values, but the latter is a bit more > costly to compute, but more importantly it is usually a lot less > convenient in use. (A third option is known_bits and known_zero_bits?) > > > Segher >
