On Tue, Nov 25, 2025 at 8:54 PM Andrew MacLeod <[email protected]> wrote: > > When bitmasks were added to value-range, they were also added to > operator==. we never added the ability to compare just the ranges and > ignore the bitmask. There have been a couple of times that would have > been convenient, but never really had a serious need. > > This patch adds equal_p () which also takes a flag indicating whether to > include bitmasks in the comparison. And the first consumer is the > on-entry cache propagator. > > We've had a number of cases over the past few months which generate > oscillating patterns in rangers cache propogator. I fixed most of them > by ensuring all the subrange bounds conformed to the bitmask.. this > prevented stray values that were not relevant from causing this sort of > oscillation. This case is slightly different. > > There is no canonical representation of bitmasks. Multiple bitmasks can > represent the same thing..
How's that? It isn't immediately obvious to me. > in this particular case, we have the cache > containing > > [irange] sizetype [12, 12][20, 20][28, 28] MASK 0x18 VALUE 0x4 So here the mask says bit 0x10 has value 0, bit 0x8 has value 0 as well. Why is VALUE not 0x0? It seems 'value' lacks canonicalization by & mask? > and when we calculate an ew on-entry range, the incoming edges are > unioned together and value_range::union_ decided to produce: > > [irange] sizetype [12, 12][20, 20][28, 28] MASK 0x1c VALUE 0x0 This has on bit more set in MASK, bit 0x4, at value 0x0. That looks either "wrong" or the range side is overly pessimistic, it should have dropped [28, 28] here? Or do we not even try to prune ranges by the bitmask? Or the other way around? Is there a single place somewhere in the ranger code that implements the range<->bitmask "interaction"? Can you point me to that? It seems that the iteration process, even if we (as it seems) treat the range and the bitmask part separately, does not ensure ranges and bitmasks either only grow or shrink. Richard. > This is a different range when the bitmask is included, and so the > propagator replaces it, and propagated this value through the CFG... > after a couple of edges and calculations this new value causes a > slightly different result, and although the range is really the same, > we just keep cycling back and forth. > > The permanent fix is to have the on-entry propagator ignore masks when > propagating values. That will stop these shenanigans going forward. The > obvious question is will we ever miss something? > > The short answer is... possibly, but it seems highly unlikely. And if it > did happen, it would never cause an incorrect result. > > This should prevent infinite loops in the propagator. It was originally > written to always converge... but that predated bitmasks being added to > irange and they add some variability which this now removes. > > Bootstraps on x86_64-pc-linux-gnu with no regressions . OK for trunk? > > Andrew >
